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

[Dmitry Gutov <dgutov@yandex.ru>]

On 01/20/2015 10:01 AM, martin rudalics wrote:

> Hmm...  They are documented in the Window Parameters section.  What do
> you miss?

No, that's good enough, thanks. I was looking for that documentation in 
window.el.

>  >> 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].
>
> No.  IMO it should be up to the user to remap `quit-window'.

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.

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.

> What I meant was that people might be used to kill the *xref* buffer
> along with closing its window or use `kill-buffer' directly on *xref*.
> And that xref should be aware of that and act accordingly, for example,
> by removing its hooks, _if any_.  Probably in `kill-buffer-hook'.

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 don't want to impose my dislike on others.  But if you want to do
> things modally you should give people means to optionally do things
> manually.

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.

> IDE lovers, for example, might want to keep a small *xref* window
> permanently open in some corner of the frame, with backward/forward
> buttons for navigating their xref history.

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?

> And I'd probably plug in a timer-driven variant of `xref-next-line'
> where moving to some particular line in the *xref* buffer window will
> display the tag in another window, provided point remains sufficiently
> long on that line.

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.