bug#31325: 27.0.50; PROPOSAL: introduce a new function to recenter without redisplaying the frame

[Drew Adams]

> > It looks like you are changing the default behavior of
> > `recenter', which is a backward-incompatible change.
> 
> That's right but only for non-interactive uses of `recenter'.  All
> interactive uses should remain backward compatible.

Sure.  That's why I said "Lisp calls".

> > Am I right about that, so that all Lisp calls of that
> > function would now need to be changed, to add a non-nil
> > 2nd arg in order to keep the same behavior?
> 
> That's right but only if the caller need to redisplay the frame.  Are
> you aware of any lisp calls that make use of that feature
> (i.e. redisplay the frame as well as recenter) ? I'm only aware of two
> uses in Flycheck and `xref-find-definitions'.  IMHO, in both cases the
> redisplay side-effect is undesirable.

I think you mean that in both cases it is undesirable _in
a terminal_, no?

Am I aware of any such calls?  That's irrelevant - to me.

And I really had no idea whether I know of such calls.  The
point is that this function has been around since Day One,
with the same behavior, and it's likely that there is code
out there that is broken by this change.  It's certainly
not enough to search the Lisp code distributed with Emacs,
to get an idea whether something is used.

However, as it turns out, I do have such calls in some of
my code.  I expected that this was not true (bad memory),
but grepping just now shows that it is.  I know it might
look like I was complaining about this change affecting my
code, but that's not the case.  I really had no idea (I'd
forgotten) that I in fact use `recenter'.

In Bookmark+ function `bmkp-handle-region-default' I use
`(recenter 1)'.  And yes, that code should redisplay.

I haven't bothered to try it in terminal mode, but if that's
a problem then doesn't it indicate a problem (bug) in Emacs
terminal mode, not in `recenter'?  Invoking a function from
Lisp is not the same as invoking it from Lisp with Emacs in
terminal mode.

And I have other uses of it, all of which should redisplay.

Icicles has multiple calls like this, where the default
value of option `icicle-recenter' is -4:

(unless (pos-visible-in-window-p) (recenter icicle-recenter))

And in Isearch+ I have this in my version of `isearch-cancel':

(when isearchp-win-pt-line (recenter isearchp-win-pt-line))

where that variable is the line number of point before
searching, relative to `window-start'.

And in `palette.el' I do this:
(when win
  (select-window win) (goto-char (point-min)) (recenter))

And in `synonyms.el' I have `(recenter 2)'.

Could I just use `set-window-point' or some such?  Maybe;
dunno.  I don't feel like debugging all such stuff, to see.
Sure, I could adapt your code change, to add the 2nd arg
(also testing the Emacs version...).  And I will, if you
go ahead with your change.

But this is not at all about my code, and it is not really
even about whether there is other code out there that uses
`recenter' expecting it to redisplay, although I expect that
there is such other code.  That's just what `recenter' does,
and it always has.  So sure, there is bound to be code that
counts on that behavior.  It's a very old function, with a
pretty simple behavior (from a use point of view, at least).

But the existence of code that would break is not really
the question.  The question is why this change should be
made to the Lisp behavior, just to accommodate a
terminal-Emacs display annoyance.  What does the one have
to do with the other?

It's really about what the _bug_ is and what it's solution
should be.  So far (but again, I haven't really read the
thread), it does not sound to me like `recenter' has a
bug.  It sounds like Emacs behaves badly in a terminal,
in this case (or in some terminals, some of the time,
perhaps).

There is nothing older than the combination of `recenter'
(same as it's always been) and Emacs in a terminal, is
there?  Why is this suddenly a bug now?

> > The reported bug was only about a problem for Emacs in
> > a terminal, right?  Can't it just be fixed to DTRT in
> > that case, without changing so much in the definition
> > and behavior of the function?
> 
> I am not sure what does the right thing mean in this case.  AFAIK, the
> patch was trying to do the right thing by keeping the interactive use
> backward compatible but prevent calling `recenter' from lisp from
> redisplaying the frame.

Use of `recenter' in a terminal is not the same as use of
`recenter' from Lisp.  Lisp is used with GUI Emacs also.

TRT surely has something to do with terminal Emacs, not
with whether or not the use is interactive, no?

Please do fix the behavior of `recenter' for Emacs in a
terminal, if it's broken.  But why "fix" it for GUI too,
if it's not broken there?  Maybe just test
`display-graphic-p'?

> > And in the old days people used Emacs mainly (and
> > originally, only) in the terminal.  Why is the terminal
> > behavior suddenly considered to be bugged?  Or given
> > that it is bugged - is changing the default behavior
> > the best fix?
> 
> I only use Emacs from the terminal, in fact I compile emacs `without-x`
> since I never use the GUI.

OK.  And did you just start seeing this bugged behavior?
Or did you just start using Emacs?  Haven't people been
using it in a terminal for decades, without this having
been reported or addressed?

Maybe it's a new problem, due to some other change.  Or
maybe it's always been there and people have just ignored
it.  In any case, IF it is to be fixed then it seems like
it should be fixed only for terminal Emacs.

> > Please ignore, if my understanding is wrong or my
> > comments on this are not helpful.
> 
> I think it is very valuable to have more feedback on the patch.  That
> said, I am still having trouble understanding what are your concerns.

Thanks; HTH.  Is it any clearer now?