bug#28864: 25.3.50; next-error-no-select does select

[Juri Linkov]

>> We could also add an alternative function based on window-local values.
>> At least, when I tried this code, it works as expected:
>
> Cool. Not something I've ever asked for, but could be helpful for
> some people.

I'm thinking about adding 3 customizable options for
next-error-find-buffer-function:

1. buffer-local - new default
2. window-local - useful for one window per each navigation buffer
3. frame-local - old implicit default now separated into its own function

> In general, next-error can jump between windows, so window-local is not
> a good fit for my mental model.

It's bad when next-error unpredictably jumps between windows.
I hope we could find a way to fix this erratic behavior.

>>> So we ignore the next-error-last-buffer change during a call to
>>> next-error-last-function, but not in any other circumstances? Like visiting
>>> a ChangeLog file manually. Maybe that's okay...
>>
>> Oh, sorry, there was a typo: it should be (with-current-buffer 
>> next-error-buffer
>> Fixed in the next version of the patch below.
>
> Thanks. But if we already ignore the change to next-error-last-buffer
> during a call to next-error-function, that should fix the currently
> discussed bug, right? Maybe even the similar behavior with next-error, too?
>
> Do we need the buffer-local-ity changes to next-error-last-buffer for that?
> Because if we do, that's okay, let's commit it and everything, but
> otherwise I'd rather wait and look for a more elegant approach (for other
> issues aside from this one).

In the last previous patch, next-error visits next-error-find-buffer,
calls next-error-function that possibly navigates to another buffer,
then sets both global and buffer-local of next-error-last-buffer.
This seems quite logical.  And it works in all my tests.

>> +        (message "Showing %s error from %s"
>> +                 (cond (reset                            "first")
>> +                       ((< (prefix-numeric-value arg) 0) "previous")
>> +                       (t                                "next"))
>
> Can arg be 0? Do we have a word for that? We might use it below, too.

We could use "current" for 0.  Could you also find a value for "last"?

>> +(defun next-error-internal ()
>> +  "Visit the source code corresponding to the `next-error' message at 
>> point."
>> +  (let ((next-error-buffer (current-buffer)))
>>       ;; we know here that next-error-function is a valid symbol we can 
>> funcall
>> -    (with-current-buffer next-error-last-buffer
>> -      (funcall next-error-function (prefix-numeric-value arg) reset)
>> +    (with-current-buffer next-error-buffer
>> +      (funcall next-error-function 0 nil)
>> +      ;; next-error-function might change the value of
>> +      ;; next-error-last-buffer, so set it later
>> +      (setq next-error-last-buffer next-error-buffer)
>> +      (setq-default next-error-last-buffer next-error-last-buffer)
>>         (when next-error-recenter
>>           (recenter next-error-recenter))
>> +      (message "Showing another error from %s" next-error-last-buffer)
>
> Is it really "another"? Or maybe it's "current", "last" or "closest" error?

Maybe just "Showing error from %s"?  Or simply "Error from %s".
Then we could simplify the above messages as well: "%s error from %s"
for e.g. "Next error from %s", "Previous error from %s", ...