From debbugs-submit-bounces@debbugs.gnu.org Sun May 12 15:47:18 2019 Received: (at submit) by debbugs.gnu.org; 12 May 2019 19:47:19 +0000 Received: from localhost ([127.0.0.1]:43380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPuRK-0002A3-90 for submit@debbugs.gnu.org; Sun, 12 May 2019 15:47:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPuRH-00029q-El for submit@debbugs.gnu.org; Sun, 12 May 2019 15:47:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:56383) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPuRC-0001XL-9c for submit@debbugs.gnu.org; Sun, 12 May 2019 15:47:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPuRB-0006JI-7U for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 15:47:10 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,RCVD_IN_DNSWL_NONE, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPuRA-0001Rt-AN for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 15:47:09 -0400 Received: from common.maple.relay.mailchannels.net ([23.83.214.38]:18472) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPuRA-0001LT-0x for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 15:47:08 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7A29321E94 for ; Sun, 12 May 2019 19:47:06 +0000 (UTC) Received: from pdx1-sub0-mail-a64.g.dreamhost.com (100-96-14-60.trex.outbound.svc.cluster.local [100.96.14.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 080DC21E84 for ; Sun, 12 May 2019 19:47:06 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a64.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 12 May 2019 19:47:06 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Cooperative-Drop: 030cc70c5b3763f7_1557690426324_44214481 X-MC-Loop-Signature: 1557690426324:164813453 X-MC-Ingress-Time: 1557690426324 Received: from pdx1-sub0-mail-a64.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a64.g.dreamhost.com (Postfix) with ESMTP id 1766480518 for ; Sun, 12 May 2019 12:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to :subject:date:message-id:mime-version:content-type; s= linkov.net; bh=hwi9dcPU79ILdvozfH/9wLrxfTQ=; b=zXPqwv9qt0X4n1h8V zzeQAUTWYyEnRvQY8kzdzjSShpBZSm5Cd4iClxq3mZQgf8wAEMXxA8ORwGUcqLKT LDRLHHCKHCCQQa4t1zO4wGXC0meBulKW+4LW1uHaYc19hKUNn3zpMaABqx7Us1y4 dWW4gvSsWzLuxSIVZnalAdn3mg= Received: from mail.jurta.org (m91-129-96-230.cust.tele2.ee [91.129.96.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 2B9C880502 for ; Sun, 12 May 2019 12:47:03 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a64 From: Juri Linkov To: bug-gnu-emacs@gnu.org Subject: xref revert-buffer Organization: LINKOV.NET Date: Sun, 12 May 2019 22:45:41 +0300 Message-ID: <87tvdzv4m2.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrledvgddugeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffuohffkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirddvfedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirddvfedtpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepsghughdqghhnuhdqvghmrggtshesghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 23.83.214.38 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) I tried to use project-find-regexp more often than rgrep, but xref misses an important feature: typing 'g' in the *xref* buffer fails with this error: Debugger entered--Lisp error: (error "Buffer does not seem to be associated with any file") signal(error ("Buffer does not seem to be associated with any file")) error("Buffer does not seem to be associated with any file") revert-buffer--default(t nil) revert-buffer(t) funcall-interactively(revert-buffer t) call-interactively(revert-buffer nil nil) command-execute(revert-buffer) From debbugs-submit-bounces@debbugs.gnu.org Thu May 23 21:52:02 2019 Received: (at 35702-done) by debbugs.gnu.org; 24 May 2019 01:52:02 +0000 Received: from localhost ([127.0.0.1]:45735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTzNJ-000507-Vz for submit@debbugs.gnu.org; Thu, 23 May 2019 21:52:02 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:38626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTzNI-0004zn-Em for 35702-done@debbugs.gnu.org; Thu, 23 May 2019 21:52:00 -0400 Received: by mail-wr1-f47.google.com with SMTP id d18so8219173wrs.5 for <35702-done@debbugs.gnu.org>; Thu, 23 May 2019 18:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lN1BFuA2Sjdu+3VxSyIbXNDYmB5R/XAe81iE4TBTLvY=; b=twUT6YQdh97te36TlGE944272Rcbkvezl+RmzjRILRQbLi2C88F7+epp1gZszVjN9T 0kRZBiHTBtH5OEQjL0M9MtmUBYCHVm9CTcoOMj9b9JkfyAFENpp0DRwmv41cioPexuQu zJYzcUN84OJpH7RuncVQvPE0N646vTsS6pyGdNDUOeOLqMj4m4qXtNdep7kXOACVLsBh jtAXs/JpczLjH/gAbWC/3srFNYNvqxD0sxV8D4zBTYUiwSPHZ2P8ez2+SNFu5TotAsCR kiVTjf3+OyTuzTlIkDBCTnwJHOmkR5WJShuSradNcE1cZRW2Un2LsylbHAgnas/9TwD+ y7hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lN1BFuA2Sjdu+3VxSyIbXNDYmB5R/XAe81iE4TBTLvY=; b=s/iyfpZhNjz6A74nP6b7N0z5SRsYJP7KnQpGVIWYb8gzwvGQU49EpZzeHbR/s4wP90 Bp7dolOkY++zPK9T0vvTAoPONuKgIZNbCKfPojB4Z6dnJZagNEDB3vuu2g5gpwq1X1w3 kNYk6TGe/TAKXptm+xAOWMh8KR0rVixiwYSoSqLwNA0Z386/JLGZVcm4RmOztRR30ZEs nVbH1v9kGRf00a0NvdB9E4smjTFuE8ICHEYzIeNQ0EqFlO2pfZ/Uhdk959+gm0PPDhQy bNpGOEAxXdb5sF/exxcMag+8GbpwuZnIjUvPo0ZED7uieT63Ns3aZ8JjxqE4Strhhjds 6QJA== X-Gm-Message-State: APjAAAXowzDfsSJFbq7SAsD1eH01rbn1/71UeNjoGpOZSdrCYaV/pryO 7GylphkZ18+Quq+/NaBQwGtfOKey X-Google-Smtp-Source: APXvYqyES+sgwwVoRyuReGMILgj/z56LOjfxpqjAOrs75qMD6+XqT4GeMJtm8GGM7wbY+Unx0VF6eQ== X-Received: by 2002:adf:fb47:: with SMTP id c7mr11502140wrs.116.1558662714059; Thu, 23 May 2019 18:51:54 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id q16sm857553wmj.17.2019.05.23.18.51.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 18:51:53 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Juri Linkov , 35702-done@debbugs.gnu.org References: <87tvdzv4m2.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Fri, 24 May 2019 04:51:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87tvdzv4m2.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Version: 27.1 On 12.05.2019 22:45, Juri Linkov wrote: > I tried to use project-find-regexp more often than rgrep, > but xref misses an important feature: typing 'g' in the > *xref* buffer Should work now, please see the commit 62349fe82a. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 04:36:50 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 08:36:50 +0000 Received: from localhost ([127.0.0.1]:46063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU5h3-0006Tj-PZ for submit@debbugs.gnu.org; Fri, 24 May 2019 04:36:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU5h1-0006TV-Cs for 35702@debbugs.gnu.org; Fri, 24 May 2019 04:36:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hU5gv-0004fX-EM; Fri, 24 May 2019 04:36:41 -0400 Received: from [176.228.60.248] (port=3239 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hU5gt-0005hd-CR; Fri, 24 May 2019 04:36:40 -0400 Date: Fri, 24 May 2019 11:36:50 +0300 Message-Id: <838suw5jvh.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: (message from Dmitry Gutov on Fri, 24 May 2019 04:51:51 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Dmitry Gutov > Date: Fri, 24 May 2019 04:51:51 +0300 > > Version: 27.1 > > On 12.05.2019 22:45, Juri Linkov wrote: > > I tried to use project-find-regexp more often than rgrep, > > but xref misses an important feature: typing 'g' in the > > *xref* buffer > > Should work now, please see the commit 62349fe82a. Thanks, but that changeset has a few problems: . the new command xref--revert-xref-buffer uses an internal name, and has no doc string . neither NEWS nor the user manual document the 'g' key in XREF buffers . it looks like this new command is not useful after M-., because I get an error message when I try using it (perhaps this is because I didn't understand its use case due to lack of docs) Let me know if I can help in fixing any of the above. (I tried to figure out what this command does and how, but quickly got lost in a chain of indirections via undocumented internal functions and variables, sorry.) From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 06:10:02 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 10:10:02 +0000 Received: from localhost ([127.0.0.1]:46129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU79F-0000F4-Kt for submit@debbugs.gnu.org; Fri, 24 May 2019 06:10:01 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:50970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU79D-0000Em-MD for 35702@debbugs.gnu.org; Fri, 24 May 2019 06:10:00 -0400 Received: by mail-wm1-f54.google.com with SMTP id f204so8765531wme.0 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 03:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=veg+N2RsCpqYtPd68SVa4FOkjfIUjMbwwNyUo8vdZf8=; b=X1qqdkraspLfsSS8W/Ws0sGYFQ+ohDRXZ5fhfgP8DV64fisowHW7BqTAD6HlFpMQwU 9MNMg95FE+MGB0kSQybDzcKgzuKmsyhBzpG/fFK5dd41dyQF8N2JRnAG98XXC1E5puNC EQqLOR83xfeWl34kLluR6VxpvhyyULCMV0EpwxvxtsZ8vqzV2zchr9TIeSRi6WZAxgAq SAvIsz/xLySBh7XweYA5MzyFGwfpYkX9bAyj5Z/KxuqYDV2azSbXzgwuTQExj2+grjnY FeoQZE6PCJd2gcCFJTkCJw1gA6nUP0eLOxM9owrHaL1dOP+R+CORxxZb4+s4ujk57H3t k0Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=veg+N2RsCpqYtPd68SVa4FOkjfIUjMbwwNyUo8vdZf8=; b=lg3Rg0M66rRkO1ErJHRtVm5f61M2jG84C4jEk3LIh+q7u7ryfsxE6/3rhbUbhJbH/o y5Zc1ogG5VvxKwY8FcK6+7dRKVV1OlQXX9wP8n2cav2DWDnTXmHMs0DW0ku/auy7XYY3 DXBNkhXZYsyS3rAxJPtz2rH/3d79/kjDgo1KB8XQ2v30nXhzzbwOzPFmh2ZpHuIOq0/U TD8HVs/uusq1ltIZalPe68eAlgGA9LoI43Ribg0IlH60DSLq4HC1Bw2P20mLOeFYt7X3 jycRKXeowIxRfF01SLs+K8oYpc/AQ5kWLDGf4I60b6sCMRk9t1zqIAAwP1fD9I2f8N1p vJjg== X-Gm-Message-State: APjAAAVuuJIX7WFOTK088H/Lds/raDRCAHZM9vM2uoKlxJp4quuHV1h5 JICnOkMO11xXMKXL8zaTJG8= X-Google-Smtp-Source: APXvYqwSNvSr5EyneAoI8+jaJAdCTvDySe/2OmexM3sLm2HQYSf/B5OoZZysdSgPNUAY3M9POXfauw== X-Received: by 2002:a05:600c:2116:: with SMTP id u22mr15088106wml.58.1558692593638; Fri, 24 May 2019 03:09:53 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id j123sm3248990wmb.32.2019.05.24.03.09.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 03:09:52 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Fri, 24 May 2019 13:09:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <838suw5jvh.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 24.05.2019 11:36, Eli Zaretskii wrote: > Thanks, but that changeset has a few problems: > > . the new command xref--revert-xref-buffer uses an internal name, Is that a problem by itself? We have other bindings that use internal command names as well. > and has no doc string How about something like: Refresh the search results by repeating the search. > . neither NEWS nor the user manual document the 'g' key in XREF > buffers I can add the NEWS entry. > . it looks like this new command is not useful after M-., because I > get an error message when I try using it (perhaps this is because > I didn't understand its use case due to lack of docs) It has been a deliberate choice to simplify the implementation. IME, you don't ever want to refresh the list of definitions. But for other search results (references, apropos, project-find-regexp, dired-do-find-regexp) it's a lot more common. Commit 49a363c875 also brings in another difference between the behaviors of xref-find-definitions and xref-find-references: the latter now shows the xref buffer even when there is just one hit. > Let me know if I can help in fixing any of the above. (I tried to > figure out what this command does and how, but quickly got lost in a > chain of indirections via undocumented internal functions and > variables, sorry.) Do you have a better idea now? Please let me know if you have any further questions. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 08:25:05 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 12:25:05 +0000 Received: from localhost ([127.0.0.1]:46223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU9Fx-0000Ac-Bo for submit@debbugs.gnu.org; Fri, 24 May 2019 08:25:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU9Fv-00009x-HV for 35702@debbugs.gnu.org; Fri, 24 May 2019 08:25:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hU9Fq-0002s0-3j; Fri, 24 May 2019 08:24:58 -0400 Received: from [176.228.60.248] (port=1395 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hU9Fp-0007od-E8; Fri, 24 May 2019 08:24:57 -0400 Date: Fri, 24 May 2019 15:25:08 +0300 Message-Id: <835zq059az.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: (message from Dmitry Gutov on Fri, 24 May 2019 13:09:50 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Fri, 24 May 2019 13:09:50 +0300 > > On 24.05.2019 11:36, Eli Zaretskii wrote: > > > Thanks, but that changeset has a few problems: > > > > . the new command xref--revert-xref-buffer uses an internal name, > > Is that a problem by itself? We have other bindings that use internal > command names as well. That's a problem, yes. Commands shouldn't be internal functions, by their very definition. > > and has no doc string > > How about something like: > > Refresh the search results by repeating the search. Given that it doesn't, at least after M-., this sounds like not all the truth. Can it be more detailed? > > . neither NEWS nor the user manual document the 'g' key in XREF > > buffers > > I can add the NEWS entry. Please do, and thanks. > > . it looks like this new command is not useful after M-., because I > > get an error message when I try using it (perhaps this is because > > I didn't understand its use case due to lack of docs) > > It has been a deliberate choice to simplify the implementation. IME, you > don't ever want to refresh the list of definitions. Well, one situation where I'd like to refresh is when the TAGS file was updated. It could mean that more identifiers matching the search string are now known. > But for other search results (references, apropos, > project-find-regexp, dired-do-find-regexp) it's a lot more common. At the very least, this should be reflected in the doc string. > Commit 49a363c875 also brings in another difference between the > behaviors of xref-find-definitions and xref-find-references: the latter > now shows the xref buffer even when there is just one hit. This should arguable be in NEWS. > > Let me know if I can help in fixing any of the above. (I tried to > > figure out what this command does and how, but quickly got lost in a > > chain of indirections via undocumented internal functions and > > variables, sorry.) > > Do you have a better idea now? Only slightly so. The code still doesn't speak to me, but I guess there isn't much that can be done about that. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 08:57:22 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 12:57:22 +0000 Received: from localhost ([127.0.0.1]:46246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU9lC-00016I-8P for submit@debbugs.gnu.org; Fri, 24 May 2019 08:57:22 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:38728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hU9l7-00015y-5S for 35702@debbugs.gnu.org; Fri, 24 May 2019 08:57:19 -0400 Received: by mail-wm1-f44.google.com with SMTP id t5so9132435wmh.3 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 05:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YhaEpahzchnOFh4FeDIjgXBcT3e8xoxjcTq6EiRh4Zk=; b=s+Lyk+QRcSMEqhW4olwFc7oYnF3L95C6upuQCa9sguLjL1vVcO3FvMXSXVZoL01fIB 8EaGofb6VdSr7ErV4bis7MfjJ6/UXC3V4Qzp6+94B1kUh1POw/oLcNCfoHOSW5QymKqW mKz1P3Pd0SaUzOV+f4GjHrgGM2bL+f80sPzSQrOFY7sY0wL0jHuM0FG0c1fta2lgVN2f yqGRNwvSxCnbC2qEixvMazqtcHbAac2f7FxDmNy/z+I5mI6yOV0ZjoTdTG8SGxDKdEs3 OjqTzp4j9Do340JB5lo6R5n7NqGQ51PPLkZPMTxitFPCf5+0DFyPVycM0bEDZDAtPmmz Q1RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YhaEpahzchnOFh4FeDIjgXBcT3e8xoxjcTq6EiRh4Zk=; b=oFRlK8prPolMuTglITd45P6U42CQFlO0OzPDuveGTibLmjEY43982vo+raGuBhXlCG ReW6dF3ff+DXXPC3L1FBcWKzk2t9J7I5o/NriP2C3knlqT9pP9eEDjRqJrhkzhx6DGHk Z2z/J9XlhjCyiN4MI7QgfVvJJNJn9cHm2dnkwx1nFWSaMJRIs3M5FG/rt8id1lUAf0iY edEkdimzj42G+/a4GRwZuH+p49A1eeod9uePFzX/+cC27sptq9JQwsDySBWSBfLTpxZ+ deMFnXGP5NIp76KN5t8hj1/Oa8gfdCQEAaydx3uEyu/IN5NpSDt52G32QssRnq1kzje+ HZ+w== X-Gm-Message-State: APjAAAXru1sW3uw6RWHUx96+0BB3ou0GP4XiEgIKhcv7OrYngu9WiAAj b18ns4v1Lwyt8jELxZrr6UU= X-Google-Smtp-Source: APXvYqwJLsTUozvrrWuPLssGJHYNjsHvY/MbG57eVQvp/ibb4azn7iD9n70vwzX7tYhrunUbx/JBJQ== X-Received: by 2002:a05:600c:114f:: with SMTP id z15mr2077982wmz.104.1558702629695; Fri, 24 May 2019 05:57:09 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id g127sm1783327wme.21.2019.05.24.05.57.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 05:57:05 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> From: Dmitry Gutov Message-ID: <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> Date: Fri, 24 May 2019 15:57:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <835zq059az.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) On 24.05.2019 15:25, Eli Zaretskii wrote: >>> Thanks, but that changeset has a few problems: >>> >>> . the new command xref--revert-xref-buffer uses an internal name, >> >> Is that a problem by itself? We have other bindings that use internal >> command names as well. > > That's a problem, yes. Commands shouldn't be internal functions, by > their very definition. I've been kind of using it as a means of denoting "we're free to change it later", which is, of course, not great for a user, but I don't feel like we're settled on a final UI. If we have a rule about private commands, though, let's fix them. But I'd prefer to do it a bit later, in a separate discussion. >>> and has no doc string >> >> How about something like: >> >> Refresh the search results by repeating the search. > > Given that it doesn't, at least after M-., this sounds like not all > the truth. Can it be more detailed? The truth is, most xref datasets support refreshing, but some don't. At least xref-find-definitions doesn't. I'm not sure we should document that in the command's docstring, though, because I think we'll end up with a more different UI for xref-find-definitions results, with a different major mode and a keymap where 'g' is simply not bound. >>> . neither NEWS nor the user manual document the 'g' key in XREF >>> buffers >> >> I can add the NEWS entry. > > Please do, and thanks. OK. Does it have to mention the command name? Here's what I have: ** Xref *** Refreshing the search results When an Xref buffer shows search results (e.g. from xref-find-references or project-find-regexp) you can type 'g' to repeat the search and refresh the results. >>> . it looks like this new command is not useful after M-., because I >>> get an error message when I try using it (perhaps this is because >>> I didn't understand its use case due to lack of docs) >> >> It has been a deliberate choice to simplify the implementation. IME, you >> don't ever want to refresh the list of definitions. > > Well, one situation where I'd like to refresh is when the TAGS file > was updated. It could mean that more identifiers matching the search > string are now known. Right, but how often would the event of updading the TAGS file with coincide with you wanting to refresh the xref-find-definitions results? Wouldn't you just do the search again with 'M-.'? This command has the easiest keybinding. >> But for other search results (references, apropos, >> project-find-regexp, dired-do-find-regexp) it's a lot more common. > > At the very least, this should be reflected in the doc string. Given that we're dealing with a certain level of abstration, and the list of commands using Xref is not limited, how would you phrase it? >> Commit 49a363c875 also brings in another difference between the >> behaviors of xref-find-definitions and xref-find-references: the latter >> now shows the xref buffer even when there is just one hit. > > This should arguable be in NEWS. How about: *** New variable 'xref-show-definitions-function' It encapsulates the logic pertinent to showing the result of xref-find-definitions. The user can change it to customize its behavior and the display of results. *** Search results show the buffer even for one hit The search-type Xref commands (e.g. xref-find-references or project-find-regexp) now show the results buffer even when there is only one hit. This can be altered by changing xref-show-xrefs-function. You can probably see a certain level of duplication there, though. >> Do you have a better idea now? > > Only slightly so. The code still doesn't speak to me, but I guess > there isn't much that can be done about that. This idea is pretty simple: instead of passing a list of search results to xref--show-xrefs, we pass an anonymous function that can be called to do the search, as well as repeat it, and returns the said list. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 10:10:18 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 14:10:18 +0000 Received: from localhost ([127.0.0.1]:46971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUAtl-0005Uh-TL for submit@debbugs.gnu.org; Fri, 24 May 2019 10:10:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56149) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUAtj-0005UM-87 for 35702@debbugs.gnu.org; Fri, 24 May 2019 10:10:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUAtc-0007mV-Ug; Fri, 24 May 2019 10:10:09 -0400 Received: from [176.228.60.248] (port=3929 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUAtX-0006LC-3p; Fri, 24 May 2019 10:10:08 -0400 Date: Fri, 24 May 2019 17:10:00 +0300 Message-Id: <831s0o54g7.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> (message from Dmitry Gutov on Fri, 24 May 2019 15:57:03 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Fri, 24 May 2019 15:57:03 +0300 > > >>> . the new command xref--revert-xref-buffer uses an internal name, > >> > >> Is that a problem by itself? We have other bindings that use internal > >> command names as well. > > > > That's a problem, yes. Commands shouldn't be internal functions, by > > their very definition. > > I've been kind of using it as a means of denoting "we're free to change > it later", which is, of course, not great for a user, but I don't feel > like we're settled on a final UI. > > If we have a rule about private commands, though, let's fix them. But > I'd prefer to do it a bit later, in a separate discussion. A command can legitimately be invoked via its name, so once it's introduced, you cannot change its name, or change the API in backward-incompatible way. If you'd prefer to reserve future changes, make the command call an internal function which does most of the job. And no, I don't think we can defer this to later. Commands must not be internal. > >> Refresh the search results by repeating the search. > > > > Given that it doesn't, at least after M-., this sounds like not all > > the truth. Can it be more detailed? > > The truth is, most xref datasets support refreshing, but some don't. At > least xref-find-definitions doesn't. > > I'm not sure we should document that in the command's docstring, though, > because I think we'll end up with a more different UI for > xref-find-definitions results, with a different major mode and a keymap > where 'g' is simply not bound. I'm not a great fan of obfuscating the docs, except for reasons of hiding internal implementation details. Why is it a problem to say that XREF buffers created by xref-find-definitions currently don't support 'g'? For that matter, why shouldn't the error message be explicit about that, instead of saying something technically accurate but quite obscure from user's POV? > >>> . neither NEWS nor the user manual document the 'g' key in XREF > >>> buffers > >> > >> I can add the NEWS entry. > > > > Please do, and thanks. > > OK. Does it have to mention the command name? I think so, yes. People may wish to bind it to a different key. > Here's what I have: > > ** Xref > > *** Refreshing the search results > When an Xref buffer shows search results (e.g. from > xref-find-references or project-find-regexp) you can type 'g' to > repeat the search and refresh the results. This should say explicitly that only some Xref functions can support refreshing the results. "E.g." can be interpreted as just an example, not that some other examples don't support this. > > Well, one situation where I'd like to refresh is when the TAGS file > > was updated. It could mean that more identifiers matching the search > > string are now known. > > Right, but how often would the event of updading the TAGS file with > coincide with you wanting to refresh the xref-find-definitions results? When the original M-. doesn't show what I expected, for example. > Wouldn't you just do the search again with 'M-.'? Yes, but that argument is true for any 'revert' action as well, isn't it? And we still have revert actions. > >> But for other search results (references, apropos, > >> project-find-regexp, dired-do-find-regexp) it's a lot more common. > > > > At the very least, this should be reflected in the doc string. > > Given that we're dealing with a certain level of abstration, and the > list of commands using Xref is not limited, how would you phrase it? I'm not sure I understand the difficulty. Regardless of the level of abstraction, 'g' invokes a specific command, and I see no problems having the doc string of that command mention other specific commands. What am I missing? > >> Commit 49a363c875 also brings in another difference between the > >> behaviors of xref-find-definitions and xref-find-references: the latter > >> now shows the xref buffer even when there is just one hit. > > > > This should arguable be in NEWS. > > How about: > > *** New variable 'xref-show-definitions-function' > It encapsulates the logic pertinent to showing the result of > xref-find-definitions. The user can change it to customize its > behavior and the display of results. > > *** Search results show the buffer even for one hit > The search-type Xref commands (e.g. xref-find-references or > project-find-regexp) now show the results buffer even when there is > only one hit. This can be altered by changing > xref-show-xrefs-function. OK, but (a) the heading sentence should end in a period; (b) please use 2 spaces between sentences. > You can probably see a certain level of duplication there, though. I don't. I see one entry referencing another, that's all. We shouldn't expect the readers to make complicated logical deliberations to understand that the first entry hints on what the second entry spells out explicitly. NEWS is not a riddle, it's a means for quickly reviewing the important changes in a new Emacs version. > >> Do you have a better idea now? > > > > Only slightly so. The code still doesn't speak to me, but I guess > > there isn't much that can be done about that. > > This idea is pretty simple: instead of passing a list of search results > to xref--show-xrefs, we pass an anonymous function that can be called to > do the search, as well as repeat it, and returns the said list. The idea is simple and clear, but trying to understand what it does in any particular invocation isn't. I tried to figure out what happens after M-., which required me to understand when is the xref--fetcher variable set and to what values. There's no easy answer to that question, neither in comments nor in the doc strings. The value is set from a function passed as an argument to a couple of other internal functions, so now I need to go deeper into the rabbit hole and understand when and how these two functions are called, and with what function as that argument. Etc. etc. -- it feels like following a deeply OO C++ code, where basically the only way to figure out how the code works is to step through the code with a debugger. Except that Edebug doesn't support generics well enough to do that, so I'm screwed even if I have the time and energy to go down that hole. It used to be possible to understand what happens in a Lisp program by just reading the code, but it no longer is, in many cases. Useful comments can go a long way towards making such investigations much easier and more efficient, but I guess I will hear counter-arguments about the need to keep comments up-to-date with the code... From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 10:26:34 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 14:26:34 +0000 Received: from localhost ([127.0.0.1]:46992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUB9W-0005xS-7l for submit@debbugs.gnu.org; Fri, 24 May 2019 10:26:34 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:52925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUB9R-0005x9-7i for 35702@debbugs.gnu.org; Fri, 24 May 2019 10:26:32 -0400 Received: by mail-wm1-f48.google.com with SMTP id y3so9626477wmm.2 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 07:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Py6MGja0BeG5K+H6+NFXAGaIcT4467+YWvLOL6iFWBw=; b=jtgGOM+BQF55Dpve8GjuXEt9xBy70pwDnt8H5RtTh77trIoo1IVvfyhecidt6tqZmi g6Jf2sGEVPEgcb3QdXyEEHAFdh4FTRb08pw+7XZOfG3JqZbRK28+ywVQNwfnX3iOcn54 KVvEWXuPOy19oXBjuKTuCugTXQ5ZOjcxhHxk0Eion0FwekuVbhOB76Ta0o3oyQkAhcJf bQkNAkfo1Is+K+2foH1NlsZz1aV3rRztDGAqhwk+moLzfWJXTq8K2Si4nwfnOgtNjJie +dNnOn6G1WQ1S3/oedc6ZTndv1rZi67XSmGojJPBqeqd/rjU5aZRX1CdnXsd+KnpmNss za9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Py6MGja0BeG5K+H6+NFXAGaIcT4467+YWvLOL6iFWBw=; b=R5WwNJGqIrjC5yEd+YGuQ6UVdastuir4v8W5Y0jWCeI6MbATAErGxvBjIqh/KLw0U0 96Fj+3GfNoTzlazxoIYRY4LvKctKVVMBNTKR8EGnAOhRfhpQdfdlq/FAtDgUD60PQg7r D2Eynn2pTl6kSdidawHAJYSFS/LmJPvYuuEs5OxR78vi4lAhOOmR7KRqnu+4cAutDdnP cnZRbLeGV+ax8R9VGrCBnRGv1ORmIJwyzJR/CPzUmcW4bGCPuL+98sgnBMhu2AlLIerT nje2oYq3Q3RhzP55BmRxczZ8aR2rX0lFPiipIauQwO8gjS+tvYzTt7z0F6ev0i+8f36n qWZw== X-Gm-Message-State: APjAAAX5V0YPDQJ1t+dzpCe3s1YIbSw6aUM1dTJ7bCYR/hQ+AqlMftZZ ZjXjvV3+3ZLQ1rMgICOi4Ns= X-Google-Smtp-Source: APXvYqxrirvN4rVH49sU9i47dLwNM1iGCHQowxYifwQScW2Kk/gV1WpOknj/2yyHFA/Iwx32l+xCEQ== X-Received: by 2002:a7b:cd0e:: with SMTP id f14mr15815231wmj.127.1558707983085; Fri, 24 May 2019 07:26:23 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id g13sm3130623wrw.63.2019.05.24.07.26.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 07:26:22 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> From: Dmitry Gutov Message-ID: <6c46e6c8-9440-5e0a-83f7-110653b97774@yandex.ru> Date: Fri, 24 May 2019 17:26:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <831s0o54g7.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 24.05.2019 17:10, Eli Zaretskii wrote: > And no, I don't think we can defer this to later. Commands must not > be internal. A later change can "fix" several commands at once. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 11:02:50 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 15:02:50 +0000 Received: from localhost ([127.0.0.1]:47035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUBic-00072Q-Bm for submit@debbugs.gnu.org; Fri, 24 May 2019 11:02:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUBia-00072C-4z for 35702@debbugs.gnu.org; Fri, 24 May 2019 11:02:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUBiT-0004zj-Na; Fri, 24 May 2019 11:02:42 -0400 Received: from [176.228.60.248] (port=3370 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUBiQ-0006ma-Bk; Fri, 24 May 2019 11:02:41 -0400 Date: Fri, 24 May 2019 18:02:11 +0300 Message-Id: <83y32v5218.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <6c46e6c8-9440-5e0a-83f7-110653b97774@yandex.ru> (message from Dmitry Gutov on Fri, 24 May 2019 17:26:20 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <6c46e6c8-9440-5e0a-83f7-110653b97774@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Fri, 24 May 2019 17:26:20 +0300 > > On 24.05.2019 17:10, Eli Zaretskii wrote: > > And no, I don't think we can defer this to later. Commands must not > > be internal. > > A later change can "fix" several commands at once. Sigh. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 11:16:09 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 15:16:09 +0000 Received: from localhost ([127.0.0.1]:47050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUBvV-0007Og-5K for submit@debbugs.gnu.org; Fri, 24 May 2019 11:16:09 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:52101) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUBvS-0007OA-UO for 35702@debbugs.gnu.org; Fri, 24 May 2019 11:16:07 -0400 Received: by mail-wm1-f52.google.com with SMTP id f10so2350511wmb.1 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 08:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=iXwtvloD59c2IJai9prURrPsSx2V5ckO87VBy+yg/h0=; b=WPfiF1p3q53VSdT8rAIYUIsZ2f8QE3ruCteDehKqCmIamIEWTVr+jqSddRH0dhJeN6 pgDEi+G2jcRS9I3/e7qIkbxCWaYCkoBVcFPunDcZVfx8VF3O3nF4uGiHpEJNTFmySNRG ZAEdNj9qF7xrUTpUzyGZwYsZrY+VoJzh9M2F3+cbuPwnAhZetiRmX2hoW0fLt8gME/vl UxD6lBVm1A0O4z8bwXxuHZYDFJSTCI+9FRkZJzyYdXPYF61RpM6Qwu3duo9RLdHSeSN7 juvZE+4DGFLZ2YQ7ELBjpftgxGsMELd8+DqZMX0iTv8o+QFIvPBFFQFxppcIouRPiqp3 ldKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=iXwtvloD59c2IJai9prURrPsSx2V5ckO87VBy+yg/h0=; b=IEEckePUEvftq5XaCC2nu86CAXhGZcvD2LepYppBCspdQHNZ8hcJ8/safpdrRk0Y+i NaBIle3ltzwGuhmr7fmwqRzIN9PPcKXlR7wE1gkRGMMcnaRdpoCLw8cHddEpju5RD5Ow QnZWZb6D5bKcAQZNiWt0XV/SdwYP1n6LIYB/WD8hVoo3pSnQKRfTGmXKR5O7CFG7GEbk DHwhf0Awhl7Sv6JLED45hCn7EH2Fvm0RDWjrPA/sLJh9p+wb5871LtW8SyIHYhGxWXdM z54fwBptQxFElifZ4UoFfLzG7LdGSRLwvl7ZZuuoryctGKj/rBtxlbGWOaEOQPrE0Ql3 gfAA== X-Gm-Message-State: APjAAAUt6UUJFwfsHo9asJzGCiz5OuV2ZNhRhlG/o3+aUEYsp1/DfXww 9lLq+u6v1jg1KwrRVQyYvGs= X-Google-Smtp-Source: APXvYqxfVf5zMy6coF2LPMXmJkaZJ8+V6f4K7Wnf3LpEQkdHMNnoBeMDgQsj+meSX8VwAXbx+W9BRw== X-Received: by 2002:a1c:48d7:: with SMTP id v206mr17135777wma.38.1558710960759; Fri, 24 May 2019 08:16:00 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id 65sm3888859wro.85.2019.05.24.08.15.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 08:15:59 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> From: Dmitry Gutov Message-ID: <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> Date: Fri, 24 May 2019 18:15:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <831s0o54g7.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------0B7C6A5C3FF3DA92DE031816" Content-Language: en-US X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) This is a multi-part message in MIME format. --------------0B7C6A5C3FF3DA92DE031816 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 24.05.2019 17:10, Eli Zaretskii wrote: >> I'm not sure we should document that in the command's docstring, though, >> because I think we'll end up with a more different UI for >> xref-find-definitions results, with a different major mode and a keymap >> where 'g' is simply not bound. > > I'm not a great fan of obfuscating the docs, except for reasons of > hiding internal implementation details. First: my point is, it's possible that it *will* always work wherever you are able to invoke it with 'g'. The Xref buffers where it wouldn't work wouldn't bind 'g'. Second: we can "obfuscate" the docs for things we're not sure about. Think forward: if we expose the Xref UI as a library for other packages in the future (and we probably will), should we allow some of them to opt out of revert-ability (for simplicity, let's say), or not? And if we do, we won't really be able to enumerate all the commands that opted out in xref--revert-xref-buffer's docstring. > Why is it a problem to say > that XREF buffers created by xref-find-definitions currently don't > support 'g'? Because it feels ad-hoc and kinda weird. The intention is to support reverting in "search results" buffers, not intentionally refuse support it in xref-find-definitions. But we can do that. > For that matter, why shouldn't the error message be > explicit about that, instead of saying something technically accurate > but quite obscure from user's POV? How would you phrase it? >> *** Refreshing the search results >> When an Xref buffer shows search results (e.g. from >> xref-find-references or project-find-regexp) you can type 'g' to >> repeat the search and refresh the results. > > This should say explicitly that only some Xref functions can support > refreshing the results. "E.g." can be interpreted as just an example, > not that some other examples don't support this. The intent was to introduce a kind of classification. That is, to call all commands that do a "wide" search as "commands that show search results". xref-find-definitions, meanwhile, might be considered a "jump with completions" command. >> Right, but how often would the event of updading the TAGS file with >> coincide with you wanting to refresh the xref-find-definitions results? > > When the original M-. doesn't show what I expected, for example. Hmm. So it's something you would really find useful? >> Wouldn't you just do the search again with 'M-.'? > > Yes, but that argument is true for any 'revert' action as well, isn't > it? And we still have revert actions. Not exactly: first, M-. is easier to invoke and re-invoke than project-find-regexp, and you are likely to edit the regexp before searching. Second, I quite frequently do something like this: - Do a search for a string with project-find-regexp, - Do *something* with the results, e.g. rename them all, - Repeat the search, to make sure I have dealt with all occurrences. So 'g' helps considerably there. And I don't have any similar scenarios for xref-find-definitions. To be clear, though, we *can* add support for reverting to xref-find-definitions as well, if you want. Just at the cost of a certain increase of complexity, see if you like the patch. xref-find-defitions-revertable.diff is attached. > OK, but (a) the heading sentence should end in a period; (b) please > use 2 spaces between sentences. OK. >> You can probably see a certain level of duplication there, though. > > I don't. I see one entry referencing another, that's all. Just to be clear: I'm referring to two of the three entries I've showed in the previous email mentioning "search-type Xref commands". >> This idea is pretty simple: instead of passing a list of search results >> to xref--show-xrefs, we pass an anonymous function that can be called to >> do the search, as well as repeat it, and returns the said list. > > > The idea is simple and clear, but trying to understand what it does in > any particular invocation isn't. I tried to figure out what happens > after M-., which required me to understand when is the xref--fetcher > variable set and to what values. There's no easy answer to that > question, neither in comments nor in the doc strings. Would a docstring saying "Function that returns a list of xrefs containing the search results" change things? > The value is > set from a function passed as an argument to a couple of other > internal functions, so now I need to go deeper into the rabbit hole > and understand when and how these two functions are called, and with > what function as that argument. Where the fetcher is created is not to hard to find, I think (only a few local variables with that name). > Etc. etc. -- it feels like following > a deeply OO C++ code, where basically the only way to figure out how > the code works is to step through the code with a debugger. It's actually more "functional programming" than OOP, and not the worst example of it (very little function composition, for instance). I can feel your pain (there's a lot of the code I have difficulty following as well), but I'm not sure where I could add comments where they wouldn't be self-evident. A couple of docstrings wouldn't hurt, though. > Except > that Edebug doesn't support generics well enough to do that, so I'm > screwed even if I have the time and energy to go down that hole. Well, at least in this case there are no generic calls between xref-find-references and xref--show-xrefs and the fetcher creation. > It used to be possible to understand what happens in a Lisp program by > just reading the code, but it no longer is, in many cases. Err, my experience of reading old Lisp code in various packages doesn't really agree. > Useful comments can go a long way towards making such investigations > much easier and more efficient, but I guess I will hear > counter-arguments about the need to keep comments up-to-date with the > code... It's not like I'm against those, but it might take a different person to identify the places that need to be commented. --------------0B7C6A5C3FF3DA92DE031816 Content-Type: text/x-patch; name="xref-find-definitions-revertable.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xref-find-definitions-revertable.diff" diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el index 6a4906a232..0fd59dc330 100644 --- a/lisp/progmodes/xref.el +++ b/lisp/progmodes/xref.el @@ -782,7 +782,10 @@ xref--analyze #'equal)) (defun xref--show-xref-buffer (fetcher alist) - (let* ((xrefs (if (functionp fetcher) (funcall fetcher) fetcher)) + (let* ((xrefs + (or + (assoc-default 'xrefs alist) + (funcall fetcher))) (xref-alist (xref--analyze xrefs))) (with-current-buffer (get-buffer-create xref-buffer-name) (setq buffer-undo-list nil) @@ -817,13 +820,16 @@ xref--revert-xref-buffer 'face 'error)))) (goto-char (point-min))))) -(defun xref--show-defs-buffer (xrefs alist) - (cond - ((not (cdr xrefs)) - (xref--pop-to-location (car xrefs) - (assoc-default 'display-action alist))) - (t - (xref--show-xref-buffer xrefs alist)))) +(defun xref--show-defs-buffer (fetcher alist) + (let ((xrefs (funcall fetcher))) + (cond + ((not (cdr xrefs)) + (xref--pop-to-location (car xrefs) + (assoc-default 'display-action alist))) + (t + (xref--show-xref-buffer fetcher + (cons (cons 'xrefs xrefs) + alist)))))) (defvar xref-show-xrefs-function 'xref--show-xref-buffer @@ -885,28 +891,29 @@ xref--read-identifier ;;; Commands (defun xref--find-xrefs (input kind arg display-action) + (xref--show-xrefs + (xref--create-fetcher input kind arg) + display-action)) + +(defun xref--find-definitions (id display-action) + (xref--show-defs + (xref--create-fetcher id 'definitions id) + display-action)) + +(defun xref--create-fetcher (input kind arg) (let* ((orig-buffer (current-buffer)) (orig-position (point)) (backend (xref-find-backend)) - (method (intern (format "xref-backend-%s" kind))) - (fetcher (lambda () - (save-excursion - (when (buffer-live-p orig-buffer) - (set-buffer orig-buffer) - (ignore-errors (goto-char orig-position))) - (let ((xrefs (funcall method backend arg))) - (unless xrefs - (xref--not-found-error kind input)) - xrefs))))) - (xref--show-xrefs fetcher display-action))) - -(defun xref--find-definitions (id display-action) - (let ((xrefs (funcall #'xref-backend-definitions - (xref-find-backend) - id))) - (unless xrefs - (xref--not-found-error 'definitions id)) - (xref--show-defs xrefs display-action))) + (method (intern (format "xref-backend-%s" kind)))) + (lambda () + (save-excursion + (when (buffer-live-p orig-buffer) + (set-buffer orig-buffer) + (ignore-errors (goto-char orig-position))) + (let ((xrefs (funcall method backend arg))) + (unless xrefs + (xref--not-found-error kind input)) + xrefs))))) (defun xref--not-found-error (kind input) (user-error "No %s found for: %s" (symbol-name kind) input)) --------------0B7C6A5C3FF3DA92DE031816-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 15:35:46 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 19:35:46 +0000 Received: from localhost ([127.0.0.1]:47383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUFyj-00025C-KC for submit@debbugs.gnu.org; Fri, 24 May 2019 15:35:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUFyh-00024v-89 for 35702@debbugs.gnu.org; Fri, 24 May 2019 15:35:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUFyb-00062J-IF; Fri, 24 May 2019 15:35:37 -0400 Received: from [176.228.60.248] (port=4197 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUFya-0007Tu-54; Fri, 24 May 2019 15:35:36 -0400 Date: Fri, 24 May 2019 22:35:32 +0300 Message-Id: <83r28n4pdn.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> (message from Dmitry Gutov on Fri, 24 May 2019 18:15:57 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Fri, 24 May 2019 18:15:57 +0300 > > >> I'm not sure we should document that in the command's docstring, though, > >> because I think we'll end up with a more different UI for > >> xref-find-definitions results, with a different major mode and a keymap > >> where 'g' is simply not bound. > > > > I'm not a great fan of obfuscating the docs, except for reasons of > > hiding internal implementation details. > > First: my point is, it's possible that it *will* always work wherever > you are able to invoke it with 'g'. The Xref buffers where it wouldn't > work wouldn't bind 'g'. Sorry, I don't understand what you are saying here. If some XREF buffers won't have the 'g' bound to a command, why do we have it bound now, and why do we have an error message when the command cannot be used? > Second: we can "obfuscate" the docs for things we're not sure about. Doc strings aren't sacred: if we change the functionality, we can modify the doc string accordingly. We do that all the time. So there's no need to avoid documenting something just because we might change it later. > Think forward: if we expose the Xref UI as a library for other packages > in the future (and we probably will), should we allow some of them to > opt out of revert-ability (for simplicity, let's say), or not? In general, I consider such changes a bad idea: XREF is a mode, and a mode should be consistent across all its users. > And if we do, we won't really be able to enumerate all the commands that > opted out in xref--revert-xref-buffer's docstring. We don't need to enumerate all of them, we only need to enumerate the ones that are provided with Emacs and are known not to support 'g'. xref-find-definitions is a very frequently used command, so saying that it doesn't support 'g' is IMO important enough. > > Why is it a problem to say that XREF buffers created by > > xref-find-definitions currently don't support 'g'? > > Because it feels ad-hoc and kinda weird. Are you going to add support for it any time soon? If so, no need to document the missing feature just yet. But if there's a real chance this will remain unsupported, we should document that now, lest we forget. > > For that matter, why shouldn't the error message be > > explicit about that, instead of saying something technically accurate > > but quite obscure from user's POV? > > How would you phrase it? XREF buffers created by xref-find-definitions cannot be reverted. > >> *** Refreshing the search results > >> When an Xref buffer shows search results (e.g. from > >> xref-find-references or project-find-regexp) you can type 'g' to > >> repeat the search and refresh the results. > > > > This should say explicitly that only some Xref functions can support > > refreshing the results. "E.g." can be interpreted as just an example, > > not that some other examples don't support this. > > The intent was to introduce a kind of classification. That is, to call > all commands that do a "wide" search as "commands that show search results". > > xref-find-definitions, meanwhile, might be considered a "jump with > completions" command. The classification should be described in more detail before it's used. Just naming it is not enough. If you add such a description, I probably won't object (but please watch out for the danger of too long descriptions which don't belong in NEWS). > >> Right, but how often would the event of updading the TAGS file with > >> coincide with you wanting to refresh the xref-find-definitions results? > > > > When the original M-. doesn't show what I expected, for example. > > Hmm. So it's something you would really find useful? Yes. > >> Wouldn't you just do the search again with 'M-.'? > > > > Yes, but that argument is true for any 'revert' action as well, isn't > > it? And we still have revert actions. > > Not exactly: first, M-. is easier to invoke and re-invoke than > project-find-regexp, and you are likely to edit the regexp before searching. I don't know about "easier", but the use case I had in mind was with original invocation via "C-u M-.". > - Do a search for a string with project-find-regexp, > - Do *something* with the results, e.g. rename them all, > - Repeat the search, to make sure I have dealt with all occurrences. > > So 'g' helps considerably there. And I don't have any similar scenarios > for xref-find-definitions. I don't think this is a reason good enough not to support 'g'. Consistency is more important than the importance of use cases. Moreover, you may not see important use cases now, but someone else might. We should only refrain from supporting a command when we are 100% sure it can never be useful. > To be clear, though, we *can* add support for reverting to > xref-find-definitions as well, if you want. Just at the cost of a > certain increase of complexity, see if you like the patch. > xref-find-defitions-revertable.diff is attached. Doesn't look to me like it adds any significant complexity. > >> You can probably see a certain level of duplication there, though. > > > > I don't. I see one entry referencing another, that's all. > > Just to be clear: I'm referring to two of the three entries I've showed > in the previous email mentioning "search-type Xref commands". Why is that "duplication"? using the same terminology is a Good Thing, as it allows the reader easier understanding what is being discussed. > > The idea is simple and clear, but trying to understand what it does in > > any particular invocation isn't. I tried to figure out what happens > > after M-., which required me to understand when is the xref--fetcher > > variable set and to what values. There's no easy answer to that > > question, neither in comments nor in the doc strings. > > Would a docstring saying "Function that returns a list of xrefs > containing the search results" change things? I meant a comment that would explain how things worked and in what scenarios. > > The value is > > set from a function passed as an argument to a couple of other > > internal functions, so now I need to go deeper into the rabbit hole > > and understand when and how these two functions are called, and with > > what function as that argument. > > Where the fetcher is created is not to hard to find, I think (only a few > local variables with that name). Finding the places where it is defined is easy enough; understanding the semantics of that isn't. The code is obfuscated by using generic names like "method", and has no comments explaining what is going on in plain English. > > Etc. etc. -- it feels like following > > a deeply OO C++ code, where basically the only way to figure out how > > the code works is to step through the code with a debugger. > > It's actually more "functional programming" than OOP, and not the worst > example of it (very little function composition, for instance). Thank God for small favors! > > It used to be possible to understand what happens in a Lisp program by > > just reading the code, but it no longer is, in many cases. > > Err, my experience of reading old Lisp code in various packages doesn't > really agree. I guess we are talking about different parts of Emacs. > It's not like I'm against those, but it might take a different person to > identify the places that need to be commented. That different person will not know enough about the code to add useful comments. Not unless they invest the effort to study and understand it. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 16:52:12 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 20:52:12 +0000 Received: from localhost ([127.0.0.1]:47452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUHAh-00049y-Kx for submit@debbugs.gnu.org; Fri, 24 May 2019 16:52:11 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:33332) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUHAg-00049k-JF for 35702@debbugs.gnu.org; Fri, 24 May 2019 16:52:11 -0400 Received: by mail-wr1-f45.google.com with SMTP id d9so11241137wrx.0 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 13:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sTin2Ib2M/cQpDwuwe3bqSTvB9uJM7J8O1ch3gtJYO0=; b=SNb3rTIOSivtR3LoSwhoaZsiueWqMshj0FTcE8C8otbDIN6sEqY+4xKjy3WeJhylQ2 eZ4/+PHT4cJnnsCQivfa6tDwJ0WPnmjI0iELmNhOOp0uGLttoiNP50eR8w4ERBI+aPXU +j1KsUiEtoBwO3GPj9+VRlUKVOULkedWe8K+ikPApjEaTf4S0NiXXYpGXVZ57EFcdMP+ jnJgxaxMHGag7WUHrCnMg9TmRJdKzqTxmOt5gpd4wWTUIwiC1vASwbcNIDAvBxaup37a hhm8ZBKuEYmmjOMzJ0srTlvaYvzfFm4D9uAtt2f0a3h6HFU0xxAzTetsDTFO7Q3nou+8 QZuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sTin2Ib2M/cQpDwuwe3bqSTvB9uJM7J8O1ch3gtJYO0=; b=jZ98261tBGFfZMh2F2GSMUWC5t7rkhG+5EAalm4eZFKp1rEkVHvd/36eq9c7Rq/EhT XPnQHn5GGY3zgoPOfreDulE9afN/44eyHxz/YT0X5KqhRB2pW8imnARKodfT+3p+k1tX IGGI35lK4W3XMqH0yx5iRLLMngVeRJfNIIJwmRwQwU5ifcikY/naBbDEviHXq6ZK7IrL Nkqls7jN5Lt4r/oRraqWtl7cWJP5sNWmaXH/niql6I3vqYqbZQr99VEh5gmgghtTdVqg 3uPpdBqHMBQwRpcbJABFXtXGeB6Ct89UU7z+nH/CcTnYqONpaBfgWXQS/4TzFlM102yT GbSQ== X-Gm-Message-State: APjAAAWh2kUM5xAQ9UOKbvogBSvZFahxrFwm/f11kl+daF8sftAjVLs3 b0hoF8GCpkA7w4nTy868nIM= X-Google-Smtp-Source: APXvYqx22TLqIgPYdUynsbwt47wQAEGWbJPz6Mk4g9jCmZyTQIKq+kg03w6L83ewKjH9Ww8+vMKNdQ== X-Received: by 2002:adf:fd4a:: with SMTP id h10mr1309005wrs.347.1558731124552; Fri, 24 May 2019 13:52:04 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id y10sm6712117wmg.8.2019.05.24.13.52.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 13:52:03 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> From: Dmitry Gutov Message-ID: <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> Date: Fri, 24 May 2019 23:51:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83r28n4pdn.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 24.05.2019 22:35, Eli Zaretskii wrote: >> First: my point is, it's possible that it *will* always work wherever >> you are able to invoke it with 'g'. The Xref buffers where it wouldn't >> work wouldn't bind 'g'. > > Sorry, I don't understand what you are saying here. If some XREF > buffers won't have the 'g' bound to a command, why do we have it bound > now, and why do we have an error message when the command cannot be > used? Because nobody has written a better alternative UI for xref-find-definitions specifically yet. But when someone(tm) does, it'll likely have a different keymap. Anyway, never mind that for now. >> Think forward: if we expose the Xref UI as a library for other packages >> in the future (and we probably will), should we allow some of them to >> opt out of revert-ability (for simplicity, let's say), or not? > > In general, I consider such changes a bad idea: XREF is a mode, and a > mode should be consistent across all its users. Fair enough. >>> Why is it a problem to say that XREF buffers created by >>> xref-find-definitions currently don't support 'g'? >> >> Because it feels ad-hoc and kinda weird. > > Are you going to add support for it any time soon? Apparently I am! >> Hmm. So it's something you would really find useful? > > Yes. OK. >> To be clear, though, we *can* add support for reverting to >> xref-find-definitions as well, if you want. Just at the cost of a >> certain increase of complexity, see if you like the patch. >> xref-find-defitions-revertable.diff is attached. > > Doesn't look to me like it adds any significant complexity. OK, I'll install it, if only to make the documentation simpler. That's something I hadn't really considered in advance. >> Just to be clear: I'm referring to two of the three entries I've showed >> in the previous email mentioning "search-type Xref commands". > > Why is that "duplication"? using the same terminology is a Good > Thing, as it allows the reader easier understanding what is being > discussed. I was thinking it would be better to coin a common term that separates "other" Xref commands from xref-find-definitions, so we don't have to enumerate them later. This distinction is also important, for instance, to make the purposes of xref-show-xrefs-function and xref-show-definitions-function clear in their docstrings. >> Would a docstring saying "Function that returns a list of xrefs >> containing the search results" change things? > > I meant a comment that would explain how things worked and in what > scenarios. Would you be surprised to hear that I don't even know where to begin? When doing something for xref.el or project.el, lately I spend quite a bit of time thinking how to make the concepts more transparent, and very little time implementing them. So I currently feel that the ideas are simple (meaning, there are no behaviors that require particular extra commentary), and the implementations are maybe too simplistic. There are much more difficult things in this package, e.g. window management. >> Where the fetcher is created is not to hard to find, I think (only a few >> local variables with that name). > > Finding the places where it is defined is easy enough; understanding > the semantics of that isn't. The code is obfuscated by using generic > names like "method", and has no comments explaining what is going on > in plain English. method uses the cl-generic infrastructure (which might be under-documented, though happily though no fault of my own), but you don't need to understand it to see what's going on with fetcher. (xref-backend-definitions backend id) returns a list of definitions. That's all what's necessary to know here. >> It's not like I'm against those, but it might take a different person to >> identify the places that need to be commented. > > That different person will not know enough about the code to add > useful comments. Not unless they invest the effort to study and > understand it. They could ask specific questions. It's harder to answer a question like "explain all this stuff to me". From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 18:36:07 2019 Received: (at 35702) by debbugs.gnu.org; 24 May 2019 22:36:07 +0000 Received: from localhost ([127.0.0.1]:47549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUInH-0006r5-CZ for submit@debbugs.gnu.org; Fri, 24 May 2019 18:36:07 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:44523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUInF-0006qb-6k for 35702@debbugs.gnu.org; Fri, 24 May 2019 18:36:06 -0400 Received: by mail-wr1-f46.google.com with SMTP id w13so3035744wru.11 for <35702@debbugs.gnu.org>; Fri, 24 May 2019 15:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9GrwS3u4rGha3vGptnjf8gkOQ8FqFUq6elIma0oSsPc=; b=SifmtX8fs/kMCkObQ2ZL3S+F0QOLDLq+Oz5IRm/TYtTKVKSdXNr6Lv21LBFvR3kMEj +lNfByNPnxDVnnqp812T43fhIrMXsMS0K7J22KSC1BqA92nLfOpA71rfZjINQdawdt7m 4gre+SYncP6UeWKUor9WrFbaqK0FkyOvzDwk3Y56oeelSdXvZTnzaYtclys+8P7cIo2u +11Za+YfX1yXTL/gHw0Kj5DLw2geD7hrvlNmZG/ehIYsvQzaZ/6D6JbrKrrLebE5Eunc RlzRTIOenV5DdVMPESniNYjp/racNpHPDSK+90DFYBUEgdFlkNJbDchtPWagb8qS3RWp tFCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9GrwS3u4rGha3vGptnjf8gkOQ8FqFUq6elIma0oSsPc=; b=nSn2JIz8LQixKz4/KN89pPsmuTm3qyzoflnZ+VbJrJufPYdjUn+SJwFBQ0c9qqbkhv G5T2irv11FA1fAqtvuGvHvd7cQd2DX5NcPzXPGImAJTtsT+FPt/ag7bodST/j3uPSJxi mB9CzNkFFwGHp9bwehe+B/0/SSm/RbbEvZZwCUheQaX4gPjj4aWbD9+dGJ5FQkTQ/Bi+ r5eluQ6Bz7St9UgHebJlj4KOry0FTWGnpV9XGQ6/psXmMjG8uy718J51un8MiBuaJHI8 AwF8xZqNPRy8SSyB0cDEFZLdnV9BH+3EdvJ8dmybQyp0q1HYkJoZeFrtXC85eDkulEuK CRmw== X-Gm-Message-State: APjAAAVd7llGBRtAzCriW752DDgPExvn95Nqrx+qzuZrUDqKGs7wZkIr p0jOwkgh6Orh7WJJbKqk+ng= X-Google-Smtp-Source: APXvYqwrBh4ohyLHq+TEUNrbEPvpfKDi/1ZgqYs1f+jMlktvNQTmPxYTSXJb9TLaaUNA2gYu9kPNiQ== X-Received: by 2002:a5d:480b:: with SMTP id l11mr6606940wrq.317.1558737359162; Fri, 24 May 2019 15:35:59 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id p8sm4172544wro.0.2019.05.24.15.35.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 15:35:57 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <6c46e6c8-9440-5e0a-83f7-110653b97774@yandex.ru> <83y32v5218.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Sat, 25 May 2019 01:35:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83y32v5218.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 24.05.2019 18:02, Eli Zaretskii wrote: >> A later change can "fix" several commands at once. > > Sigh. Okay then. Fixed the new one now. NEWS entries added as well. From debbugs-submit-bounces@debbugs.gnu.org Sat May 25 03:39:50 2019 Received: (at 35702) by debbugs.gnu.org; 25 May 2019 07:39:50 +0000 Received: from localhost ([127.0.0.1]:48061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hURHS-0005Wk-AA for submit@debbugs.gnu.org; Sat, 25 May 2019 03:39:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hURHQ-0005WU-18 for 35702@debbugs.gnu.org; Sat, 25 May 2019 03:39:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hURHK-0007tF-7M; Sat, 25 May 2019 03:39:42 -0400 Received: from [176.228.60.248] (port=4661 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hURHJ-0001Od-LB; Sat, 25 May 2019 03:39:42 -0400 Date: Sat, 25 May 2019 10:39:39 +0300 Message-Id: <83h89j3rus.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> (message from Dmitry Gutov on Fri, 24 May 2019 23:51:58 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Fri, 24 May 2019 23:51:58 +0300 > > >> Just to be clear: I'm referring to two of the three entries I've showed > >> in the previous email mentioning "search-type Xref commands". > > > > Why is that "duplication"? using the same terminology is a Good > > Thing, as it allows the reader easier understanding what is being > > discussed. > > I was thinking it would be better to coin a common term that separates > "other" Xref commands from xref-find-definitions, so we don't have to > enumerate them later. > > This distinction is also important, for instance, to make the purposes > of xref-show-xrefs-function and xref-show-definitions-function clear in > their docstrings. I'm fine with coming up with some classification of these commands. But I think the classification should be in the manual, not in NEWS. > >> Would a docstring saying "Function that returns a list of xrefs > >> containing the search results" change things? > > > > I meant a comment that would explain how things worked and in what > > scenarios. > > Would you be surprised to hear that I don't even know where to begin? Yes. > When doing something for xref.el or project.el, lately I spend quite a > bit of time thinking how to make the concepts more transparent, and very > little time implementing them. So I currently feel that the ideas are > simple (meaning, there are no behaviors that require particular extra > commentary), and the implementations are maybe too simplistic. > > There are much more difficult things in this package, e.g. window > management. I didn't mean to imply that the stuff we were discussing is the only one that is painful to decipher. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat May 25 11:48:10 2019 Received: (at 35702) by debbugs.gnu.org; 25 May 2019 15:48:10 +0000 Received: from localhost ([127.0.0.1]:49408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUYu2-0008UC-5N for submit@debbugs.gnu.org; Sat, 25 May 2019 11:48:10 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:38073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUYu0-0008Ty-LF for 35702@debbugs.gnu.org; Sat, 25 May 2019 11:48:09 -0400 Received: by mail-wm1-f54.google.com with SMTP id t5so11880217wmh.3 for <35702@debbugs.gnu.org>; Sat, 25 May 2019 08:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=89r8h4IkwnyeXhDCz/DdrKdmHF21cXlbdo5uYwtznVg=; b=sapT7HlMeJEGlw0H86HORuA5JWO6+JVyO7FDNsvF++MnLkH2FBdKbsyKIV/v3JFo31 2Vd1ZkTnsqCUgk54NXVZLGa8kKgD9oNSx+vsC4jTzUxTNgLUjYp6oXwPKDMIQkbLl6DR IhNf1wNOgtju0MYPqzdvX5Iz+gK8bE1p70o1NjFpHW/psBDvspr2n/guzyX9eaQbkND8 6ee5arqy/MtgUu09Wzamd3+NZvSwVL1Cl2YUm76j/09vwhomnffuruvoLR7GeYX0yqHr 5Uo6OvWIU1eGL6oC7a2rsuOg7hKOUgzd4YDRa99QGT93/XZzK/kaBZLM0M3SPOpmoqWL pvmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=89r8h4IkwnyeXhDCz/DdrKdmHF21cXlbdo5uYwtznVg=; b=WWaoUrV/DPqWem+/jAomel6mthfDbyh8M5BzZxyUwqIiQSZ7ypwXDCJKLU8cI8FCYf WOllCmAsNYlOEMLFJvEjx4B9GrbiG2Seb3xeTtzguV3/ZkDaF1grp14FX56Ev6XTG3HJ RAYIFo5NVOGtzoCVNNmXOv4Wu/f6GP05a9ah+vdiKb7xJ/OpQnggsh9/MunEMXkc49Sc RTHoEWC5KWwIGJ7vxE5+Skeb2L+2WvVeuDqiAHTmADD6f08hmE3POQVuU6+53vu9WbQ8 tlPTnKPP9+ySI6VDW9OvQdZKlSNqgpd4XMzFt22M8EjhJpaJv2mcmMI16F6FyLCZ1+ZZ RKeg== X-Gm-Message-State: APjAAAWHLd0VjfGXY4/jc0RA9C527wdjck3p6p2vAXXAqwLyQIL0IyzZ LkroJ0055Q89AARnkL1wlVQ= X-Google-Smtp-Source: APXvYqzSKdLdxGAo13NkDwxH6WDKCTTqHGEruw074uxzSux7OEhPVrpWviYYUEQ+qC4C1HXs7pxu7Q== X-Received: by 2002:a05:600c:230a:: with SMTP id 10mr19480910wmo.13.1558799282654; Sat, 25 May 2019 08:48:02 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id z5sm9347567wmi.34.2019.05.25.08.48.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 08:48:01 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> From: Dmitry Gutov Message-ID: <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> Date: Sat, 25 May 2019 18:47:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83h89j3rus.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 25.05.2019 10:39, Eli Zaretskii wrote: > I'm fine with coming up with some classification of these commands. > But I think the classification should be in the manual, not in NEWS. If you have any suggestions for better docstrings for there variables, I'd like to know. >> Would you be surprised to hear that I don't even know where to begin? > Yes. Well, it's true. I don't know where the comments will work better for the recent additions than just reading the code. Do you have any particular questions? From debbugs-submit-bounces@debbugs.gnu.org Sat May 25 12:06:32 2019 Received: (at 35702) by debbugs.gnu.org; 25 May 2019 16:06:32 +0000 Received: from localhost ([127.0.0.1]:49427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUZBo-0000b9-0y for submit@debbugs.gnu.org; Sat, 25 May 2019 12:06:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUZBm-0000as-8v for 35702@debbugs.gnu.org; Sat, 25 May 2019 12:06:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUZBg-0008L2-N5; Sat, 25 May 2019 12:06:24 -0400 Received: from [176.228.60.248] (port=4532 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUZBS-0002US-Eq; Sat, 25 May 2019 12:06:14 -0400 Date: Sat, 25 May 2019 19:06:10 +0300 Message-Id: <831s0m4iz1.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> (message from Dmitry Gutov on Sat, 25 May 2019 18:47:57 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Sat, 25 May 2019 18:47:57 +0300 > > Do you have any particular questions? Thanks, but the purpose of my rant was not to follow up with questions. If I cannot convince you to clarify the code by adding more comments, then I guess I failed, and let's drop this. From debbugs-submit-bounces@debbugs.gnu.org Sat May 25 12:14:50 2019 Received: (at 35702) by debbugs.gnu.org; 25 May 2019 16:14:50 +0000 Received: from localhost ([127.0.0.1]:49436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUZJp-0000pZ-TY for submit@debbugs.gnu.org; Sat, 25 May 2019 12:14:50 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:42390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUZJo-0000pJ-Dc for 35702@debbugs.gnu.org; Sat, 25 May 2019 12:14:48 -0400 Received: by mail-wr1-f48.google.com with SMTP id l2so12791235wrb.9 for <35702@debbugs.gnu.org>; Sat, 25 May 2019 09:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=898ftCxhvqjwKxrDwOenv+psRCzWvgJHCS7T+9HCjbg=; b=jJC15BhOyWZQWfOvZZey4IZGvVFK7eogonQLR06GQ/eGESb+Htoyq80L2VKLz230Wa BSsx2w3PtKaAYMqIOfUJKwV4OVPIqMX3wLk6InYG3VQIXc1hROwTdkRMakIzQDhMauvW KYlKsEK9OXOeloayZwU2Zt/82JI+wFQzJWLMLahGCvokF+xdh5buLvSjtSMzD4xHrDUB 8w7+K7j7ObXafYTlBHRU8M/vwhMo/E2to1UsOTmiiY75L42OBsUqBosdWHCjDUdK9anL cBWjrZcSseHiy5/nNJZuovZSHOuFOapu76DwoQ76IS1WaVWAgo8StNb4v/daMJ+4kwjX zQUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=898ftCxhvqjwKxrDwOenv+psRCzWvgJHCS7T+9HCjbg=; b=t2Hkf/AX2mXxs/bOhFVSuBRoQ4JeUvmsmVq/ATHpTNXwj8U2Vv8yX3a6ZGH8g7JZIU A40P4Bdf7D9pA3514ahoJNVZjzWRquseA8kdp4f+/DtVLmTHX3kHiiKnNcDURbXPUaX8 iPrueHx15CgpE1nlXjNWK5iJLxL00UQgEAX5KFsrExHrYHl3Az69pb3HgGP5YK0MOFhp TknEX3R/Zr2labzafWBXLLe6t4jiS+tCfTINTGz4nYNMMpZD9zL9Xp4R9ZOddhYirllV BTKH2lJMO/lomdmPfnkEe2N8DZlLk6u2xh1C/CYGaytsoTncVZxy7MzxHWmDbul4viU4 VO7Q== X-Gm-Message-State: APjAAAUSdXn1V9uKYuG5RWWxpZbE3csCAh703KV7MIgEAYLJdydB8/21 XwxnAqnlYv1Z1J9Qli/5Z/A= X-Google-Smtp-Source: APXvYqwQHs/IyaqvpKa1gWqCd5szq0apQxDC9jvcuePbzXyKvwcZjwY+G+6Z1vpys52tKebnXxuO1A== X-Received: by 2002:adf:ce8e:: with SMTP id r14mr3878121wrn.289.1558800882470; Sat, 25 May 2019 09:14:42 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id o12sm126969wmh.12.2019.05.25.09.14.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 09:14:41 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Sat, 25 May 2019 19:14:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <831s0m4iz1.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 25.05.2019 19:06, Eli Zaretskii wrote: > Thanks, but the purpose of my rant was not to follow up with > questions. If I cannot convince you to clarify the code by adding > more comments, then I guess I failed, and let's drop this. I was meaning to put at least some of the answers into comments. But OK. From debbugs-submit-bounces@debbugs.gnu.org Sat May 25 12:49:42 2019 Received: (at 35702) by debbugs.gnu.org; 25 May 2019 16:49:42 +0000 Received: from localhost ([127.0.0.1]:49481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUZrZ-0001lO-M1 for submit@debbugs.gnu.org; Sat, 25 May 2019 12:49:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUZrX-0001l9-MN for 35702@debbugs.gnu.org; Sat, 25 May 2019 12:49:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUZrR-0002xR-NO; Sat, 25 May 2019 12:49:33 -0400 Received: from [176.228.60.248] (port=3209 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUZrR-0004gx-0V; Sat, 25 May 2019 12:49:33 -0400 Date: Sat, 25 May 2019 19:49:32 +0300 Message-Id: <83y32u32eb.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: (message from Dmitry Gutov on Sat, 25 May 2019 19:14:39 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Sat, 25 May 2019 19:14:39 +0300 > > On 25.05.2019 19:06, Eli Zaretskii wrote: > > Thanks, but the purpose of my rant was not to follow up with > > questions. If I cannot convince you to clarify the code by adding > > more comments, then I guess I failed, and let's drop this. > > I was meaning to put at least some of the answers into comments. Then I already asked those questions. The most important one is what values can the fetcher variable have, and in what situations (i.e., triggered by what command(s)) will we see each value. From debbugs-submit-bounces@debbugs.gnu.org Sat May 25 17:33:46 2019 Received: (at 35702) by debbugs.gnu.org; 25 May 2019 21:33:46 +0000 Received: from localhost ([127.0.0.1]:49788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUeIU-0007tt-Ed for submit@debbugs.gnu.org; Sat, 25 May 2019 17:33:46 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:46518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUeIS-0007te-F2 for 35702@debbugs.gnu.org; Sat, 25 May 2019 17:33:44 -0400 Received: by mail-wr1-f41.google.com with SMTP id r7so13169683wrr.13 for <35702@debbugs.gnu.org>; Sat, 25 May 2019 14:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZU7yy/5zfMCIA2JCz6yQXP3AiG0bSCkUNk4zfoCV3wU=; b=PvALscrHBjznR2IDwotUoBq8e1joGEwrREd/2m2kp/g4fKiiseRd64TQpcRDEqUbLD tqlTBFCeD44E7+/sHptjla026/4aG/GNs6+qOJyEOjTv1bXI/vBuJtSSNzCYOZ6e3y9T WhTJJaOIGJfjksw0/ml9CiVh1PmZgXb+SJoyqiJAMGh/6bC65hgO+q1i+OQ853NNTavd UV9XrR74aAAIxMg2ycWWO0oeIQTnG2O4DE4uGCKhMRTlyy5/FO++j1rr4+sGhxDYpiwk rmKqf1sa/fagHgI0j55V8wyy/UBniGjIsbBid80hqhJ++flqYO+nIGAEdl1xKLjOdax5 06EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZU7yy/5zfMCIA2JCz6yQXP3AiG0bSCkUNk4zfoCV3wU=; b=Fw1bcOs8WKKGHMAgtkT85d+ZwTKyVfXgHqXBapSSeWiG46gFXO403TnNzoMNqf5PJI 9FPPiIfRl/Ua02lMKYoVFsSlWMAfjsC+ir2Y/R2ahVrDoQDXBbUAV9oieC4vpljfZUq8 qQgiCo8503lh34KqapknFrFl8s1hVDEJOvdXQvIelAsvbnT2Z36CmaehSwBYrxdqJXwc Kbekkflx4AMjyTZM6SaRrnjEe+IRjIFJLAi+w7YYriN0SOQCCqOEx3NSU8XS0hrPA2nf 59Fg/pjY3IzhU12ytN4VIcI0cv+KVSknuXTIbh+3wZUsWXCWjdbj2YwpLRT5qABqrQ3K 8gUQ== X-Gm-Message-State: APjAAAWfvEWfsiiMI30dcLIQq0bqzzvOthiTxK+VFepnkH845DyIe8Cz 0N0nfLcDikXIcShjjr7/FA/KhycG X-Google-Smtp-Source: APXvYqxFV46nADaHXtxjVhlAwqt6euzgcH6qhID8ZRGHIBmIZpuBN5dgaVOfkDtpMb7avjtNk7D0Gg== X-Received: by 2002:adf:ef83:: with SMTP id d3mr5334170wro.253.1558820018374; Sat, 25 May 2019 14:33:38 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id y17sm5452532wrp.70.2019.05.25.14.33.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 May 2019 14:33:37 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> <83y32u32eb.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Sun, 26 May 2019 00:33:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83y32u32eb.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 25.05.2019 19:49, Eli Zaretskii wrote: > Then I already asked those questions. The most important one is what > values can the fetcher variable have, and in what situations (i.e., > triggered by what command(s)) will we see each value. It's akin to asking what values could revert-buffer-function have: different ones. Every command that uses the xref UI is responsible for creating such a function (though most of current ones have a common implementation only parameterized by KIND, see xref--create-fetcher). I have added some more docstrings and a comment, though. Hope they clear up a few things. From debbugs-submit-bounces@debbugs.gnu.org Sun May 26 12:45:03 2019 Received: (at 35702) by debbugs.gnu.org; 26 May 2019 16:45:03 +0000 Received: from localhost ([127.0.0.1]:51588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUwGd-0004X5-4H for submit@debbugs.gnu.org; Sun, 26 May 2019 12:45:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUwGa-0004WE-RQ for 35702@debbugs.gnu.org; Sun, 26 May 2019 12:45:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUwGT-00054g-B4; Sun, 26 May 2019 12:44:53 -0400 Received: from [176.228.60.248] (port=3617 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hUwGS-0007mg-35; Sun, 26 May 2019 12:44:53 -0400 Date: Sun, 26 May 2019 19:44:53 +0300 Message-Id: <83ef4l2mii.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: (message from Dmitry Gutov on Sun, 26 May 2019 00:33:33 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> <83y32u32eb.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Sun, 26 May 2019 00:33:33 +0300 > > On 25.05.2019 19:49, Eli Zaretskii wrote: > > > Then I already asked those questions. The most important one is what > > values can the fetcher variable have, and in what situations (i.e., > > triggered by what command(s)) will we see each value. > > It's akin to asking what values could revert-buffer-function have: > different ones. Although in theory there could indeed be an infinite number of values, in practice the current actual set is very small, and can be easily described. If you want to avoid the (IMO imaginary) danger of implying there could be no other values, you can say explicitly that other values are possible. IOW, useful documentation should be general, but not too general. If being general means refraining saying something that could potentially help the reader understand the software and use it, then you are probably on the wrong side of "too general". > I have added some more docstrings and a comment, though. Hope they clear > up a few things. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon May 27 10:54:39 2019 Received: (at 35702) by debbugs.gnu.org; 27 May 2019 14:54:39 +0000 Received: from localhost ([127.0.0.1]:53774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVH1K-0008Cm-PA for submit@debbugs.gnu.org; Mon, 27 May 2019 10:54:39 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:45624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVH1I-0008CU-Mt for 35702@debbugs.gnu.org; Mon, 27 May 2019 10:54:37 -0400 Received: by mail-wr1-f42.google.com with SMTP id b18so17152753wrq.12 for <35702@debbugs.gnu.org>; Mon, 27 May 2019 07:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cgahU+jegortqulanHVxn9Bi3wo9nzi62lanJpzLI6Q=; b=Ma2tw9UA+/gk0ytI/lxgz2/GoCxXU1GG/p9hAeT4xEP+rwgQkvjCEMDaWDzLtgJ8ly DZqxkJBkams3VNj+GcpkWfyiQUZyMyk4HFoSVxKKOpMS7yREYG1GvsRfhW20ciVRDQkQ oWsT2UM7rWkza8sfTo9gty94+hVWM/WaK/KRIftMpQNNDPlOyevNO4x9sQATEOA4wMU7 Buzhp9aJP/XDrGPOX9kPZGpOusCqPd0F3DBQnP39JkrhJDQ6QSN4FjLrIGVx8zHpuR5o WXon5KO05GMLvm8QZdOurwtX2r11jR92ucpdBQvcYk+UI3jfag//xnRnCVjITsQKa0EU 9KKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cgahU+jegortqulanHVxn9Bi3wo9nzi62lanJpzLI6Q=; b=fZ3esjaYg/IhNLMkVqNc4k90cVqiCdoccgPr4f52t3bEPZarTaPBA4DU5fczfHRFLf p9VSkLvvkYBceCCRcLUI5uFINwn6PvFeL0Rypb0UVZHiUGAHqRB1vVD9NmVCxuEWD7cu 0U6vzMMpvsM3aYWusAPHEFiJskH6FE6BhOp1bVK23vAMgV1n/DTGMetVQjKtbMbnyZ+3 M877TunemB0aig0rhgkCwHn1GKvRQiE8O4Xxk2JaZDZgNbym2mDc3FMqbggDUZ5c1131 bI+Cp1/Lp4Ai65sg0SuFnmxT746kY955G1BvSS+Wqs9xAgNfPg1lfK4ZLSwo+Ga2I+ZA asBw== X-Gm-Message-State: APjAAAWZf+lRTC8wLfc9o6+f0JtV4OTftLx+3U+rapoh2Cl5fELI7jXJ hq7GpVnrJoj81/qIgF8+900= X-Google-Smtp-Source: APXvYqy9F3k5IqgIj6GMwKNE6NQIQrLYRchE2vwVfDsx8Vvp6PI9GDQXz4OCYTh/z5VD6XhYlPns1A== X-Received: by 2002:adf:ee0c:: with SMTP id y12mr50813690wrn.34.1558968869416; Mon, 27 May 2019 07:54:29 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id j206sm16315764wma.47.2019.05.27.07.54.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2019 07:54:26 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> <83y32u32eb.fsf@gnu.org> <83ef4l2mii.fsf@gnu.org> From: Dmitry Gutov Message-ID: <6d64213c-75f2-ab84-7ec3-2fee4e3742e0@yandex.ru> Date: Mon, 27 May 2019 17:54:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83ef4l2mii.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 26.05.2019 19:44, Eli Zaretskii wrote: >> It's akin to asking what values could revert-buffer-function have: >> different ones. > > Although in theory there could indeed be an infinite number of values, > in practice the current actual set is very small, and can be easily > described. And yet, it's not hugely important to the code that's calling it. Or for understanding of said code (call the function, show the returned items; call it again if the user wants to refresh the list). All that as long as the function adheres to its protocol. It's like 'cons' in that regard. Or 'seq-map.' So previously, we passed a list of xrefs to xref--show-xrefs. Now we pass a function that returns said list instead. It's a fairly trivial change by itself, so if the previous state of affairs was okay, the new one shouldn't require a lot of new documentation. > If you want to avoid the (IMO imaginary) danger of > implying there could be no other values, you can say explicitly that > other values are possible. That depends on the level of detail you would like. The minimal level description is in the docstring, and it should be fine for understanding any code that uses FETCHER. There is some intermediate description in xref--create-fetcher's docstring, though I don't know how much it helped. But if you want a description that goes to the lower level and describes *everything*, like how it uses obarray for Elisp and usually scans the contents of TAGS otherwise... I don't think it's helpful for understanding of the xref--create-fetcher variable, or the corresponding function arguments. It's simply not the appropriate place for it (not sure if an "overview" section would be better, but the manual seems like the best place; we could add some extra commentary in elisp-mode.el or etags.el if the existing ones seem not enough). > IOW, useful documentation should be general, but not too general. If > being general means refraining saying something that could potentially > help the reader understand the software and use it, then you are > probably on the wrong side of "too general". On the other hand, I wouldn't want to bog the description of a fairly clean abstraction (if I do say that myself) with incidental details. Or duplicate information that's already available elsewhere. The general way we describe our code could, of course, be improved, but I don't subscribe to the idea that we can have a general overview of the system no matter where we start reading the code. From debbugs-submit-bounces@debbugs.gnu.org Mon May 27 12:31:52 2019 Received: (at 35702) by debbugs.gnu.org; 27 May 2019 16:31:52 +0000 Received: from localhost ([127.0.0.1]:53910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVIXP-0002ha-Kj for submit@debbugs.gnu.org; Mon, 27 May 2019 12:31:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVIXN-0002hM-GA for 35702@debbugs.gnu.org; Mon, 27 May 2019 12:31:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVIXH-0002vh-NT; Mon, 27 May 2019 12:31:43 -0400 Received: from [176.228.60.248] (port=3367 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hVIXG-0002I5-WE; Mon, 27 May 2019 12:31:43 -0400 Date: Mon, 27 May 2019 19:31:46 +0300 Message-Id: <831s0j3ll9.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <6d64213c-75f2-ab84-7ec3-2fee4e3742e0@yandex.ru> (message from Dmitry Gutov on Mon, 27 May 2019 17:54:21 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> <83y32u32eb.fsf@gnu.org> <83ef4l2mii.fsf@gnu.org> <6d64213c-75f2-ab84-7ec3-2fee4e3742e0@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Mon, 27 May 2019 17:54:21 +0300 > > On 26.05.2019 19:44, Eli Zaretskii wrote: > > >> It's akin to asking what values could revert-buffer-function have: > >> different ones. > > > > Although in theory there could indeed be an infinite number of values, > > in practice the current actual set is very small, and can be easily > > described. > > And yet, it's not hugely important to the code that's calling it. It was important to me. You prodded me to ask questions and tell you what made the code reading difficult for me, remember? Now you are trying to convince me that it isn't a difficulty, or that I shouldn't be asking for that? > So previously, we passed a list of xrefs to xref--show-xrefs. Now we > pass a function that returns said list instead. It's a fairly trivial > change by itself, so if the previous state of affairs was okay, the new > one shouldn't require a lot of new documentation. You assume that the previous state was okay, which is not a given. Moreover, you assume that the reader remembers there was a list before, and can therefore "easily" translate this knowledge to the new code, instantly understanding that the function now returns the list that was previously passed as argument. That's a lot of assumptions. > > If you want to avoid the (IMO imaginary) danger of > > implying there could be no other values, you can say explicitly that > > other values are possible. > > That depends on the level of detail you would like. The minimal level > description is in the docstring, and it should be fine for understanding > any code that uses FETCHER. I hope you trust me to have read every bit of comment and doc string I could possibly find before complaining. > The general way we describe our code could, of course, be improved, but > I don't subscribe to the idea that we can have a general overview of the > system no matter where we start reading the code. See, I was sure I will get a response like that, which was why I marked what I wrote as . If you don't intend to humor requests for more documentation of the code's workings, then why do you respond to such rants? It's a waste of time for both of us, and the result is known in advance. I guess I should simply shut up about this next time. Sorry I wasn't wiser this time. From debbugs-submit-bounces@debbugs.gnu.org Tue May 28 10:10:15 2019 Received: (at 35702) by debbugs.gnu.org; 28 May 2019 14:10:15 +0000 Received: from localhost ([127.0.0.1]:56699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVcnv-00071v-5O for submit@debbugs.gnu.org; Tue, 28 May 2019 10:10:15 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:42517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVcnt-00071Z-MU for 35702@debbugs.gnu.org; Tue, 28 May 2019 10:10:14 -0400 Received: by mail-wr1-f45.google.com with SMTP id l2so20407520wrb.9 for <35702@debbugs.gnu.org>; Tue, 28 May 2019 07:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iBzRaAHg/CL+U9nsNGStvhwGJ5hq0a3XRkKLBjx92X8=; b=Y/gBWWNsA3tci8No1jk0wqm+fd/H02xL91WF2vrg9kK1dtQhFafOoL4HKC/3qT8gIy 8ehUw8e5nypA22L2ivqZcoWfx0nqd3Ubb7a2kgUYkosS2p9Ks+u6zIdI8IiAQ556tIfk k4QJvMDc2axmB0Xc+BPubehkqrntezqIogEtH+2c7teGNa02prtH0lQhnJCXuLaqO9Sl KzZHvcbAKM4nOWGW9zxUENnAIA00QHiuis/rIUyqzrxLsgqiXDLveAEPRUG5HRtLWC9o RSxbW4s/vdYlXVDSsyxCdR7KB5BWTNoZSosR8RcaQHAJLBXddfPIy+BTmYafNI922Ic/ p5sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iBzRaAHg/CL+U9nsNGStvhwGJ5hq0a3XRkKLBjx92X8=; b=h4lAkpJlWR9HyfjPH82B8mdGUkgilJTSrUmItbig3eggc/FP4MCqyA2bg/BvCQcPxK whDhDCWKRQOMD8Lp53iLqmHciz/gK6X/35NkRdlaP9EZBs7So5mHQWotpNNSMaoE1iDM e4sBHb4mJoXM6Aa3hpJbi1YmCZg1/6GTXHuP92L+SVMyG7fpWet1uBaZCXA9uuc/2+EO m88PMAJQEPi3WfNF27zHjTDEXi7mtQYTmWgfgmGpWDYTx13UxVhGEaMDQetZCTMaMqUv UpEV+Ht9W0uWx6J2X0kPirbUvTJo0b9h4FHlasUUMCpPL3xenZWf1WRUdgrdD7lg1k3o SuEQ== X-Gm-Message-State: APjAAAXO4qC9Wk6SWhYRurCbA/a6bwzIhs7117yr5/1nL5eaUkf1NQAz aokRqBDOMPnLJj/0Vpj/MCI= X-Google-Smtp-Source: APXvYqxdCXvVmzIw10J91zC+9RTadBbI/TRRImnJbGWrNtCuj38AmKxFiIegeajf39dxQvi27CVkuQ== X-Received: by 2002:adf:e649:: with SMTP id b9mr32742835wrn.195.1559052607512; Tue, 28 May 2019 07:10:07 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id v13sm2686932wmj.46.2019.05.28.07.10.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 07:10:04 -0700 (PDT) Subject: Re: bug#35702: xref revert-buffer To: Eli Zaretskii References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> <83y32u32eb.fsf@gnu.org> <83ef4l2mii.fsf@gnu.org> <6d64213c-75f2-ab84-7ec3-2fee4e3742e0@yandex.ru> <831s0j3ll9.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Tue, 28 May 2019 17:10:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <831s0j3ll9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 27.05.2019 19:31, Eli Zaretskii wrote: >>> Although in theory there could indeed be an infinite number of values, >>> in practice the current actual set is very small, and can be easily >>> described. >> >> And yet, it's not hugely important to the code that's calling it. > > It was important to me. You prodded me to ask questions and tell you > what made the code reading difficult for me, remember? Now you are > trying to convince me that it isn't a difficulty, or that I shouldn't > be asking for that? I'm sorry to disappoint. I'm sure you understand that there are question I can answer but I'd have hard time converting into code comments. Here are the kinds of questions I was hoping for: * What does this function/variable do, or what is it for? These can translate into [improvements for] docstrings or into top Commentary. * Given the stated purpose of why does it implement it *this particular way*? These can translate into inline comments. As such, I can answer your question (probably already did), but since IMO they are not about xref--fetcher or xref--show-defs, I can't put the answers into nearby comments. So instead I ended up thinking of a few questions along these lines and asking them myself, hence the resulting commit that added some more documentation. >> So previously, we passed a list of xrefs to xref--show-xrefs. Now we >> pass a function that returns said list instead. It's a fairly trivial >> change by itself, so if the previous state of affairs was okay, the new >> one shouldn't require a lot of new documentation. > > You assume that the previous state was okay, which is not a given. > Moreover, you assume that the reader remembers there was a list > before, and can therefore "easily" translate this knowledge to the new > code, instantly understanding that the function now returns the list > that was previously passed as argument. That's a lot of assumptions. Hopefully the new docstrings will make understanding all that easier anyway. >> That depends on the level of detail you would like. The minimal level >> description is in the docstring, and it should be fine for understanding >> any code that uses FETCHER. > > I hope you trust me to have read every bit of comment and doc string I > could possibly find before complaining. Well, there was some extra documentation added in the meantime, and I'm not sure how you feel about it. >> The general way we describe our code could, of course, be improved, but >> I don't subscribe to the idea that we can have a general overview of the >> system no matter where we start reading the code. > > See, I was sure I will get a response like that, which was why I > marked what I wrote as . If you don't intend to humor requests > for more documentation of the code's workings, then why do you respond > to such rants? I did suggest some other places where new commentary can go. Maybe you could propose something else as well, now that I've tried to explain why your previous suggestion is hard for me to do. If I interpreted it correctly, at least. From debbugs-submit-bounces@debbugs.gnu.org Tue May 28 14:41:56 2019 Received: (at 35702) by debbugs.gnu.org; 28 May 2019 18:41:56 +0000 Received: from localhost ([127.0.0.1]:57110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVh2p-0002i1-Ub for submit@debbugs.gnu.org; Tue, 28 May 2019 14:41:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVh2o-0002ho-9e for 35702@debbugs.gnu.org; Tue, 28 May 2019 14:41:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37078) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVh2h-0006At-Ej; Tue, 28 May 2019 14:41:48 -0400 Received: from [176.228.60.248] (port=4338 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hVh2f-00054n-O5; Tue, 28 May 2019 14:41:47 -0400 Date: Tue, 28 May 2019 21:41:53 +0300 Message-Id: <83sgsyzaj2.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: (message from Dmitry Gutov on Tue, 28 May 2019 17:10:03 +0300) Subject: Re: bug#35702: xref revert-buffer References: <87tvdzv4m2.fsf@mail.linkov.net> <838suw5jvh.fsf@gnu.org> <835zq059az.fsf@gnu.org> <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> <831s0o54g7.fsf@gnu.org> <9869e4ac-1b36-b605-22a8-b8bab4910132@yandex.ru> <83r28n4pdn.fsf@gnu.org> <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> <83h89j3rus.fsf@gnu.org> <28666899-1fcd-947b-8b2d-528f786302a9@yandex.ru> <831s0m4iz1.fsf@gnu.org> <83y32u32eb.fsf@gnu.org> <83ef4l2mii.fsf@gnu.org> <6d64213c-75f2-ab84-7ec3-2fee4e3742e0@yandex.ru> <831s0j3ll9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35702 Cc: 35702@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 35702@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Tue, 28 May 2019 17:10:03 +0300 > > > It was important to me. You prodded me to ask questions and tell you > > what made the code reading difficult for me, remember? Now you are > > trying to convince me that it isn't a difficulty, or that I shouldn't > > be asking for that? > > I'm sorry to disappoint. Relax, I wasn't disappointed. From unknown Fri Jun 13 11:02:30 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 26 Jun 2019 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator