|
From: | Dmitry Gutov |
Subject: | bug#28864: 25.3.50; next-error-no-select does select |
Date: | Sun, 5 Nov 2017 15:37:15 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0 |
On 11/3/17 12:00 AM, Juri Linkov wrote:
I'm not sure either can be congruent to all next-error-function applications. Some next-error source buffers contain their own errors (so buffer-local is natural), and others point to errors in other buffers (supposing they can learn to open those in the same window, window-local might be fitting). But both kinds are there, and all users deal with both.They can learn to open those in the same window by the patch below.
If 'next-error', from any source, opens its target in the same window, does that make window-local storage essentially the same as frame-local in practice?
3. frame-local - old implicit default now separated into its own functionThat doesn't sound like a sufficient description: the old default also includes visibility-based logic. So it's not just one value per frame.Do you think we should use the real frame-parameter?
I almost never use more than one frame, so I wouldn't know. But if you use a frame-parameter only, won't that break backward compatibility?
is the new next-error-find-buffer stuff necessary to fix the current bug? Or is suppressing the change to next-error-last-buffer during next-error-function calls enough for that?The key point is (setq next-error-last-buffer) after (funcall next-error-function), not before.
Thanks. So maybe we can split your patch into two parts: one that fixes the complaint in just this bug report, and the rest that aims to improve the general behavior.
We could push the first one right away, and continue discussing the second one. I'd like to see some new voices too, not just us two.
Why not use "current" here as well? After all, we pass 0 to next-error-function here.OK, here is the next patch:
Thanks.
[Prev in Thread] | Current Thread | [Next in Thread] |