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

[John Shahid]

Drew Adams <drew.adams@oracle.com> writes:

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

Are you confusing redisplaying the window that is displaying the buffer
with clearing and redisplaying the entire tty frame ? This patch
addresses the latter.  To be clear, `recenter' will redisplay the window
displaying the buffer and this patch doesn't change that behavior.

If you meant the former (i.e. clearing and redisplaying the entire
frame), can you elaborate on why `bmkp-handle-region-default' would need
to do that.

Clearing and redisplaying the entire frame causes unnecessary flickering
that makes the eating experience very poor.  To my knowledge this
behavior is only needed for interactive users in order to clear the
terminal and redisplay Emacs' content.  For example, this could happen
if the kernel decides to print messages or if a background process
prints to the same terminal that Emacs is using.  I fail to see how a
lisp call would be interested in redisplaying the entire frame.

> 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)'.

Same as above.  I don't see how these calls to `recenter' should
redisplay the entire frame as opposed to redrawing the single window
that displays the buffer.

> 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.

I don't think you have to use a different lisp function or add the extra
argument, unless of course I misunderstood what these libraries are
trying to do.

> 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?

I don't think anything changed other than having the desire and time to
fix this behavior.  I have been noticing this behavior for a while but
didn't bother debugging it to figure out the root cause.

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

As I mentioned previously, the behavior of `recenter' in the GUI hasn't
changed, assuming you use the default value of `recenter-redisplay'.

> 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'?

I don't think we need to do anything special for the GUI.  As I
mentioned above `recenter' doesn't redisplay the entire frame by default
when a GUI is being used.  This is because redisplaying the frame is
unnecessary for GUI, since they don't suffer from the same problem as
terminals where some random process could clobber the display.

>> > 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?

I have been using Emacs for almost 10 years now.  I don't think there is
anything new about this except for my desire to fix it now.

> 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?

I don't think so.  The way you argue against merging the patch makes me
believe you misunderstood the intended change.  I suggest you read the
entire thread as well as the original help-gnu-emacs [1] thread for more
context.

[1]: http://lists.gnu.org/archive/html/help-gnu-emacs/2018-04/msg00326.html