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 15:57:03 +0300 [thread overview]
Message-ID: <710f0ac1-80d7-6db8-7653-c58f93b6f4ab@yandex.ru> (raw)
In-Reply-To: <835zq059az.fsf@gnu.org>
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.
next prev parent reply other threads:[~2019-05-24 12:57 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 [this message]
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
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=710f0ac1-80d7-6db8-7653-c58f93b6f4ab@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.