GNU bug report logs - #19466
25.0.50; xref-find-def doesn't find C functions

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 19466 <at> debbugs.gnu.org, Helmut Eller <eller.helmut <at> gmail.com>
Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions
Date: Mon, 19 Jan 2015 15:32:30 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.