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

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/16/2015 09:47 AM, martin rudalics wrote:

> so I think you should push the `quit-window' based solution to trunk
> (which, from the few testing I gave it, seems to handle this case well).

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

> One thing that has annoyed me ever since is the buffers that pile up
> while browsing tags.  I always dreamt of a good heuristic to get rid of

I thought of that problem too, but it seems less important than 
willy-nilly changing the window configuration, hence the currently 
discussed attempt to alleviate it.

> them.  Maybe you could try making provisions like
>
> (1) this buffer is killable because it has been probably visited
>      exclusively by and only accidentally during xrefing, and
>
> (2) have the command that quits the *xref* buffer optionally kill the
>      buffers marked in (1).

`xref--quit' could definitely be used for it.

> A heuristic for (1) could go as follows:
>
>    The buffer was created during xrefing, the window was never selected
>    while it showed that buffer and either its buffer was "immediately"
>    replaced by another xrefed one or `xref--quit' was invoked.

One question is, how will we know that if was never selected? 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?

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

> You might also consider setting `other-window-scroll-buffer' to the
> window used by `xref-show-location-at-point'.
>
> martin, who'd prefer (user-error "No reference at point")

Done.