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

[martin rudalics]

> Pushed. I'd really like you to look at the implementation, though.

I didn't see any flaws in it.  In any case we'll find out pretty soon if
there are.

>> (2) have the command that quits the *xref* buffer optionally kill the
>>      buffers marked in (1).
>
> `xref--quit' could definitely be used for it.

That's what I thought.  Note in this context that some people might have
globally bound `quit-window' to some key other than 'q' and might want
to quit *xref* with that.  It's obviously up to them whether
`quit-window' does something additional in that context but it certainly
should do something "intuitively useful".  For example, with a prefix
argument it will kill the *xref* buffer and any hooks set up by xrefing
should get removed.

> One question is, how will we know that if was never selected?

Via `buffer-list-update-hook'?  That is, if a buffer (1) was created by
xref but (2) never got "promoted" by `buffer-list-update-hook', then
such a buffer is eligible for being killed quietly.

> Use a window-configuration-change-hook? Do we keep the newly added
> value there indefinitely, or when will `remove-hook' be called if the
> user never presses `q' in the xref buffer?

I'd say as soon as the *xref* buffer stops being displayed.  If a user
does that and a buffer gets killed by the way and the user later on
decides to redisplay that buffer via xrefing, she has to pay the price
of re-reading that buffer from file.  That's why this feature should be
optional.

> Overall, solving both problems would be easier if xref used a more
> restricting interface which would never allow to switch to the
> temporarily displayed buffers until the user made their choice (but
> sure, they could scroll the other window).
>
> Maybe with `Electric-command-loop'.

I profoundly dislike modal windows.  We should never restrict displaying
or perusing the *xref* buffer in any way.  Anything hardcoded here will
get you into troubles with users and inhibit developers to improve the
interface.

martin