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

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/19/2015 10:28 AM, martin rudalics wrote:

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

To me, xref--save-to-history looks like it's exploiting implementation 
details that could change in the future. Possibly because I haven't 
found good documentation for the quit-restore values.

> 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.

You obviously mean [remap quit-window]. Forgot about 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.

I wouldn't say "prefix argument means kill" is inherently intuitive, but 
sure, a remapped command should mimic behavior of the original command 
as close as possible (I just wasn't aware of it).

>  > 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.

Sounds good. And as soon a it's run, it can change some local variable, 
and then the function will remove itself from the hook.

>  > 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.

Actually, with the above scheme there's no real need to call 
`remove-hook' from elsewhere. And if the xref buffer was buried 
sometime, then switched to again, and a buffer in question still wasn't 
selected in the meantime? Let it be killed, no great loss.

> 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.

Does what?

I think it might be fine to always delete the "temporary" buffers if 
`xref--quit' was called with a prefix, as an initial implementation. 
After all, if the user doesn't mind having extra file buffers around, 
they'd also probably just bury xref.

> 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.

I wouldn't necessarily agree (the keys and allowed commands could be 
customizable), but ok, let's not go that way.