[Top][All Lists]

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

Re: tags-loop-continue

From: Eli Zaretskii
Subject: Re: tags-loop-continue
Date: Fri, 22 Jan 2016 16:08:17 +0200

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 22 Jan 2016 13:13:20 +0300
> On 01/22/2016 09:59 AM, Eli Zaretskii wrote:
> >> And if someone asks for it back, ask them to go fix bug#20489 first.
> >
> > I was about to suggest this myself.  So yes, let's do that.  If we
> > indeed try harder to leave the *xref* buffer visible, the need for
> > this integration would be lower.
> On the other hand, while *xref* is visible, `next-error' will keep 
> working for its results (it's item 1 in next-error-find-buffer).
> That's how `next-error' stayed useful for e.g. *compilation* all these 
> years. And it's fairly handy to call `next-error' to go to the next 
> result, without having to switch back to *compilation*.

The problem is not with *compilation* alone or with *xref* alone, the
problem happens when you have both of them.

> So, do we really remove the integration? Up to you.

I think removing it will leave us with a lesser evil.  Maybe leaving
that code commented out with a reference to bug#20489 would increase
the discoverability of the problem, and we could have a solution
sooner, I don't know.

We could also have a defcustom (to enable this in *xref*), but that
sounds too much, no?


reply via email to

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