From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 35702@debbugs.gnu.org, juri@linkov.net
Subject: bug#35702: xref revert-buffer
Date: Fri, 24 May 2019 23:51:58 +0300 [thread overview]
Message-ID: <2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru> (raw)
In-Reply-To: <83r28n4pdn.fsf@gnu.org>
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".
next prev parent reply other threads:[~2019-05-24 20:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-12 19:45 bug#35702: xref revert-buffer Juri Linkov
2019-05-24 1:51 ` Dmitry Gutov
2019-05-24 8:36 ` Eli Zaretskii
2019-05-24 10:09 ` Dmitry Gutov
2019-05-24 12:25 ` Eli Zaretskii
2019-05-24 12:57 ` Dmitry Gutov
2019-05-24 14:10 ` Eli Zaretskii
2019-05-24 14:26 ` Dmitry Gutov
2019-05-24 15:02 ` Eli Zaretskii
2019-05-24 22:35 ` Dmitry Gutov
2019-05-24 15:15 ` Dmitry Gutov
2019-05-24 19:35 ` Eli Zaretskii
2019-05-24 20:51 ` Dmitry Gutov [this message]
2019-05-25 7:39 ` Eli Zaretskii
2019-05-25 15:47 ` Dmitry Gutov
2019-05-25 16:06 ` Eli Zaretskii
2019-05-25 16:14 ` Dmitry Gutov
2019-05-25 16:49 ` Eli Zaretskii
2019-05-25 21:33 ` Dmitry Gutov
2019-05-26 16:44 ` Eli Zaretskii
2019-05-27 14:54 ` Dmitry Gutov
2019-05-27 16:31 ` Eli Zaretskii
2019-05-28 14:10 ` Dmitry Gutov
2019-05-28 18:41 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2103dba2-60ec-9752-1ab8-71ed66fafe63@yandex.ru \
--to=dgutov@yandex.ru \
--cc=35702@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.