bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions
Date: Mon, 19 Jan 2015 15:32:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]