[Top][All Lists]

[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: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> 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

> > 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?

reply via email to

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