From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#35702: xref revert-buffer Date: Fri, 24 May 2019 23:51:58 +0300 Message-ID: <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="138309"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: 35702@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 24 22:55:52 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUHEF-000ZtF-Vs for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2019 22:55:52 +0200 Original-Received: from localhost ([127.0.0.1]:60034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUHEE-00063G-UL for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 May 2019 16:55:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUHE8-00062Y-Fd for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 16:55:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUHBW-00038c-Iw for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 16:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33909) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hUHBW-00038Q-CB for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 16:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hUHBW-0004B7-4y for bug-gnu-emacs@gnu.org; Fri, 24 May 2019 16:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 May 2019 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35702 X-GNU-PR-Package: emacs Original-Received: via spool by 35702-submit@debbugs.gnu.org id=B35702.155873113215999 (code B ref 35702); Fri, 24 May 2019 20:53:02 +0000 Original-Received: (at 35702) by debbugs.gnu.org; 24 May 2019 20:52:12 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <83r28n4pdn.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159732 Archived-At: 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".