bug#46119: 28.0.50; this-error-recenter

[Tino Calancha]

Juri Linkov <juri@jurta.org> writes:

>> I like to see the pulse highlight, as with `next-error-no-select',
>> that's why I call `next-error-function' here.
>> [I customize `next-error-highlight' and `next-error-highlight-no-select' to
>> 3 s]
>
> Woundn't such pulse highlighting be useful for all cases,
> not only compilation and occur?
Yes, that helps to drive the eye to the position of the line.

> Then you can use:
>
>   (with-selected-window (other-window-for-scrolling)
>     (recenter-top-bottom)
>     (pulse-momentary-highlight-one-line (point)))
>
> and customize pulse-delay to 3 s, and pulse-iterations to 1.

There is a problem: It is not guaranteed that
Occur/Grep will scroll the right target window.  Users might have
divided the frame in 3 or more windows.

For Occur/Grep, to ensure we scroll the right window, we would need to
let bind `other-window-scroll-buffer' to the right targets (available at
*Occur* and *Grep* as text properties); that part complicates the code.


The original implementation, i.e.:
+    (funcall next-error-function 0 nil)
+    (recenter-top-bottom arg)
+    (pop-to-buffer next-error-last-buffer)))

automatically takes care of finding the target.

I'd prefer adding them as two separated entities:
- recenter-other-window:
  as you have suggested, including the pulse.

- recenter-this-error (or this-error-recenter):
  For occur/grep with the original proposal.

Another small benefit is that for occur/grep, the pulse highlight
automatically behaves the same as in `next-error-no-select':
it matches only the occurrence/error.

Do you agree with adding two separated commands?