bug#19466: 25.0.50; xref-find-def doesn't find C functions

[martin rudalics <rudalics@gmx.at>]

 > If you're arguing to remove the `q' mapping in
 > xref--xref-buffer-mode-map, that's a pretty circumstantial way to go
 > about it. And I disagree.

By no means.  `q' should do what it does now.

 > The user is in control either way (they can modify the above map just
 > as well), but the binding should be there by default because it's a
 > part of the core functionality. `xref-goto-xref' also calls
 > `xref--quit', and having one without the other by default would be
 > weird.

Sure.  All I mean is that if the user decides to bury the *xref* buffer
and later switches back to it, it should be functional as before.  And
if the user kills the buffer, there should not be any traces left.  Both
seem to work at the moment IIUC.  Here I only wanted to state that there
might be other means to stop/suspend xrefing than via `xref--quit'.

 > The hooks won't be a real problem. Currently, it sets up none. If we
 > use buffer-list-update-hook, that it will fire at most once in each
 > used buffer, and then remove itself. There's no harm leaving it in,
 > and either way, it's a pretty unimportant detail.

I think that the "remove itself" feature is good and if it can be done I
see no problems.

 > Conceptually, doing things in a different way would correspond to a
 > different value of xref-show-xrefs-function. Everyone's welcome to try
 > creating a different interface.

`xref--show-xref-buffer' is good as it is.  `xref-show-xrefs-function'
might be useful to emulate the old behavior where the buffer is never
shown but some keystroke is used to jump to the next tag.

 > While I like the sound of this, I'm having hard time imagining how
 > xrefs would work with back-forward buttons. Suppose the user performed
 > a jump to a definition. What contents will xref buffer have after
 > that? The same?

Yes.  But the buttons could get me to a buffer showing the result(s) of
the next and previous tag searches.  Basically what M-. followed by
previous-/next-history-element should do (and for some reason doesn't do
here yet).

 > That's trivial to implement (I'm thinking post-command-hook with
 > sit-for rather than a timer), but the hard part is creating, naming
 > and documenting the yet-another user option, as far as I'm
 > concerned. Feel free to try your hand at it.

I'll do that here as soon as I know where I want to place my *xref*
window within a frame.

In addition to what Eli reclaimed earlier: I need M-. to work in texi
buffers, the Emacs manuals, from *Help*, backtrace and customization
buffers.  How set things up for that?

Thanks, martin