[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23179: 25.0.92; Restore `M-,' to continue etags search
From: |
Eli Zaretskii |
Subject: |
bug#23179: 25.0.92; Restore `M-,' to continue etags search |
Date: |
Tue, 05 Apr 2016 18:56:36 +0300 |
> Cc: 23179@debbugs.gnu.org, andlind@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 5 Apr 2016 18:27:57 +0300
>
> On 04/05/2016 06:12 PM, Eli Zaretskii wrote:
>
> > Copying a function only to change a line or two sounds extreme to me.
>
> The idea is that the other UI should really be a new
> xref-show-xrefs-function, that's what that variable is there for (you
> can make it a defcustom). It would be better to avoid coupling the two UIs.
If the difference will prove to be more significant, I can see the
point.
> > The point is to be able to tell people who, like Anders, don't want to
> > see the UI to use the option to get what they want, instead of arguing
> > with them trying to convince them that the UI is for their best.
>
> I'm just wondering if the new looks were a minor part of his complaint,
> and not seeing the first match quickly, a more significant one.
It is, but IMO we need to solve both issues.
> Here's a more technical concern: if you revisit the discussion
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489, we've mentioned that
> next-error-find-buffer, like it's currently written, really wants the
> next-error-last-buffer to be visible. Otherwise, it's prone to switch to
> using next-error-function from some other, visible buffer.
I thought that if one invokes next-error immediately after xref
collected the matches, this danger is avoided. Isn't that true?
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, (continued)
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Anders Lindgren, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/03
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Anders Lindgren, 2016/04/04
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/04
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/04
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search,
Eli Zaretskii <=
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, John Wiegley, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, John Wiegley, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, John Wiegley, 2016/04/05
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Dmitry Gutov, 2016/04/06
- bug#23179: 25.0.92; Restore `M-,' to continue etags search, Eli Zaretskii, 2016/04/05