bug#35702: xref revert-buffer

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 35702@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.