bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Geza Herman]

The bug is, that in certain circumstances, emacs moves the point by 
using some kind of scrolling for "(goto-char (point-max))", instead of 
just jumping.

Repro:

- create a file using the little C program at the end (it produces a 
large text to stdout, you'll need to redirect it to some file)

- open the file with "emacs -Q generated.txt"

- with M-:, execute this:

    (progn
      (setq scroll-conservatively 101)
      (font-lock-add-keywords nil '(((lambda (bound)) (1 'error prepend 
t))) t)
      (goto-char (point-max)))

Notice that emacs doesn't jump to the end immediately as usual, but it 
does some kind of very fast scrolling.

(With long-line-threshold set to nil, the issue doesn't happen)

In my real case, a much smaller file produces this problem. Also, Emacs 
doesn't go to the end of the file, but stops somewhere in the middle (I 
was unable to reproduce this issue with a simple configuration). So to 
go to the end of the file I have to run "(goto-char (point-max))" 
multiple times. Interestingly, "M->" works fine. But if I remove the 
recenter call at the end of "end-of-buffer", it also has this odd behavior.


Here is the C program:

#include <stdio.h>
#include <stdlib.h>

int main() {
     for (int i=0; i<200000; i++) {
         int len = 100 + (rand()&0x7f);
         if (i==5000) len = 60000;
         for (int j=0; j<len; j++) {
             printf("x");
         }
         printf("\n");
     }
}


In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
  cairo version 1.16.0) of 2023-08-30, modified by Debian built on
  x86-csail-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Debian GNU/Linux trixie/sid

Configured using:
  'configure --build x86_64-linux-gnu --prefix=/usr
  --sharedstatedir=/var/lib --libexecdir=/usr/libexec
  --localstatedir=/var/lib --infodir=/usr/share/info
  --mandir=/usr/share/man --with-libsystemd --with-pop=yes
  --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.1/site-lisp:/usr/share/emacs/site-lisp
  --with-sound=alsa --without-gconf --with-mailutils
  --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
  --sharedstatedir=/var/lib --libexecdir=/usr/libexec
  --localstatedir=/var/lib --infodir=/usr/share/info
  --mandir=/usr/share/man --with-libsystemd --with-pop=yes
  --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.1/site-lisp:/usr/share/emacs/site-lisp
  --with-sound=alsa --without-gconf --with-mailutils
  --with-native-compilation --with-cairo --with-x=yes
  --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
  -ffile-prefix-map=/build/reproducible-path/emacs-29.1+1=. 
-fstack-protector-strong
  -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
  -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
   value of $LC_ALL: C.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp comp-cstr
warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode
cl-loaddefs cl-lib bytecomp byte-compile rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 100665 12371)
  (symbols 48 7141 0)
  (strings 32 26857 2252)
  (string-bytes 1 845777)
  (vectors 16 20215)
  (vector-slots 8 367701 18494)
  (floats 8 50 17)
  (intervals 56 2211 0)
  (buffers 984 12))

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Thu, 26 Oct 2023 19:04:42 +0200
> From: Geza Herman <geza.herman@gmail.com>
> 
> The bug is, that in certain circumstances, emacs moves the point by 
> using some kind of scrolling for "(goto-char (point-max))", instead of 
> just jumping.
> 
> Repro:
> 
> - create a file using the little C program at the end (it produces a 
> large text to stdout, you'll need to redirect it to some file)
> 
> - open the file with "emacs -Q generated.txt"
> 
> - with M-:, execute this:
> 
>     (progn
>       (setq scroll-conservatively 101)
>       (font-lock-add-keywords nil '(((lambda (bound)) (1 'error prepend 
> t))) t)
>       (goto-char (point-max)))
> 
> Notice that emacs doesn't jump to the end immediately as usual, but it 
> does some kind of very fast scrolling.

I didn't yet try to reproduce this, but just reading the description:
why do you consider this behavior a problem, let alone a bug?

> In my real case, a much smaller file produces this problem. Also, Emacs 
> doesn't go to the end of the file, but stops somewhere in the middle (I 
> was unable to reproduce this issue with a simple configuration).

This can legitimately happen if the last line has tall characters or
you use line-spacing or something similar.  Again, why is it a
problem, as long as EOB is visible after that?

> So to go to the end of the file I have to run "(goto-char
> (point-max))" multiple times. Interestingly, "M->" works fine. But
> if I remove the recenter call at the end of "end-of-buffer", it also
> has this odd behavior.

Which isn't surprising, since with the 'recenter' call removed,
end-of-buffer is just (goto-char (point-max)).

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Herman, Géza]

On 10/26/23 20:25, Eli Zaretskii wrote:
> I didn't yet try to reproduce this, but just reading the description:
> why do you consider this behavior a problem, let alone a bug?
I think that pressing the "go to the end of the buffer" key should go to 
the end of the buffer without any weird-looking scrolling, and it should 
do it immediately, not in ~0.5 seconds. Without the 
long-line-optimization, it does that. In this case, the optimization is 
not an optimization, but makes things worse.

I've just disabled this optimization, not just because of this. It's 
also not ideal that if I run beginning-of-visual-line at the end of a 
long line, the point only moves ~1000 characters to the left, instead of 
moving to the beginning. I didn't report this problem, because I assume 
it is known (I suppose it's by design how the optimization works?), so I 
just give this as a feedback on the long-line-optimization feature here.


>> In my real case, a much smaller file produces this problem. Also, Emacs
>> doesn't go to the end of the file, but stops somewhere in the middle (I
>> was unable to reproduce this issue with a simple configuration).
> This can legitimately happen if the last line has tall characters or
> you use line-spacing or something similar.  Again, why is it a
> problem, as long as EOB is visible after that?

The buffer is a simple ASCII file, all characters between 32-127 and 
newline. There are no tall characters. My line-spacing is nil. The 
problem is that EOB is not visible. Emacs stops at line 19232, but the 
file has 48263 lines. I didn't analyze this problem too deeply, because 
I thought that the fact that emacs scrolls in this case is already a bad 
thing. And it's likely the cause of the scrolling is similar to the 
stopping, because both problem go away with long-line-threshold set to nil.


>> So to go to the end of the file I have to run "(goto-char
>> (point-max))" multiple times. Interestingly, "M->" works fine. But
>> if I remove the recenter call at the end of "end-of-buffer", it also
>> has this odd behavior.
> Which isn't surprising, since with the 'recenter' call removed,
> end-of-buffer is just (goto-char (point-max)).
Yes, but it is still weird how can a final recenter call cause a 
difference. The point movement happened earlier, and it is fixed by a 
later recenter call. But yeah, I suppose the scrolling happens later, 
during redisplay, or similar. I just reported this fact because it may 
help identifying the issue.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Thu, 26 Oct 2023 21:12:55 +0200
> Cc: 66764@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> On 10/26/23 20:25, Eli Zaretskii wrote:
> > I didn't yet try to reproduce this, but just reading the description:
> > why do you consider this behavior a problem, let alone a bug?
> I think that pressing the "go to the end of the buffer" key should go to 
> the end of the buffer without any weird-looking scrolling, and it should 
> do it immediately, not in ~0.5 seconds.

I'm not sure what you mean by "should go to the end of the buffer
without any weird-looking scrolling".  The Lisp program you posted
moves point to the end of the buffer, but how to reflect that best on
display is the decision made by the display engine, and it can
legitimately be by scrolling the window (IIUC what you mean by
"weird-looking scrolling").  As for ~0.5 seconds, I don't think I see
this mentioned in your original report, so I'm guessing there are some
aspects of this behavior that you haven't described in full yet, or
maybe I didn't understand your description.  Maybe when I generate the
file with your program, I will understand it better.

> I've just disabled this optimization, not just because of this. It's 
> also not ideal that if I run beginning-of-visual-line at the end of a 
> long line, the point only moves ~1000 characters to the left, instead of 
> moving to the beginning. I didn't report this problem, because I assume 
> it is known (I suppose it's by design how the optimization works?), so I 
> just give this as a feedback on the long-line-optimization feature here.

Yes, this is by design.

> >> In my real case, a much smaller file produces this problem. Also, Emacs
> >> doesn't go to the end of the file, but stops somewhere in the middle (I
> >> was unable to reproduce this issue with a simple configuration).
> > This can legitimately happen if the last line has tall characters or
> > you use line-spacing or something similar.  Again, why is it a
> > problem, as long as EOB is visible after that?
> 
> The buffer is a simple ASCII file, all characters between 32-127 and 
> newline. There are no tall characters. My line-spacing is nil. The 
> problem is that EOB is not visible. Emacs stops at line 19232, but the 
> file has 48263 lines.

You are saying that Emacs stops and doesn't go further towards EOB
afterwards?

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

OK, I think I see the root cause of the problem: it's your
font-lock-keywords setting, viz.:

 (font-lock-add-keywords nil '(((lambda (bound)) (1 'error prepend t))) t)

Without this setting, everything works as expected, and goto-char goes
to the EOB almost instantaneously, even when scroll-conservatively is
set to a large value.

AFAIU, the font-lock-keywords setting above causes the display engine
to call this function every time it moves across some chunk of text,
which slows down redisplay.  This shows with scroll-conservatively set
to a large value because Emacs then attempts to find the minimum
amount of scrolling the screen in order to bring point into the view.

It is a known fact that modes which use advanced font-lock settings
should adapt to the long-line situation (when the function
long-line-optimizations-p returns non-nil), so I think you should
modify your font-lock settings to avoid this problem in that case.

CC'ing Gregory in case I missed something in this scenario.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Herman, Géza]

On 10/27/23 07:46, Eli Zaretskii wrote:


> You are saying that Emacs stops and doesn't go further towards EOB
> afterwards?
Yes. I press my "goto-EOB" key, then it does this weird scrolling, and 
Emacs stops in the middle of the buffer. Then I need to press "goto-EOB" 
again to actually reach EOB.

I haven't tried to make a minimal reproducible example yet.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Herman, Géza]

On 10/27/23 08:50, Eli Zaretskii wrote:
> AFAIU, the font-lock-keywords setting above causes the display engine
> to call this function every time it moves across some chunk of text,
> which slows down redisplay.  This shows with scroll-conservatively set
> to a large value because Emacs then attempts to find the minimum
> amount of scrolling the screen in order to bring point into the view.
As far as I understand, if the buffer is fully font-locked, then this 
function won't be called again, unless the buffer is modified. So this 
shouldn't be a problem. But even if this is not true, I've been using 
this setting for a long time, I didn't notice any performance problems 
with it.

> It is a known fact that modes which use advanced font-lock settings
> should adapt to the long-line situation (when the function
> long-line-optimizations-p returns non-nil)
This setting comes from a package named hl-todo. I believe it is done 
this way so it only highlights TODO items which are in comments/strings. 
Maybe there is a better way to achieve this, I don't know.


> so I think you should
> modify your font-lock settings to avoid this problem in that case.
I turned off long-line optimizations instead, because it causes other 
problems as well (mentioned in my previous email).

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Fri, 27 Oct 2023 11:22:22 +0200
> Cc: 66764@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> 
> 
> On 10/27/23 07:46, Eli Zaretskii wrote:
> 
> 
> > You are saying that Emacs stops and doesn't go further towards EOB
> > afterwards?
> Yes. I press my "goto-EOB" key, then it does this weird scrolling, and 
> Emacs stops in the middle of the buffer. Then I need to press "goto-EOB" 
> again to actually reach EOB.
> 
> I haven't tried to make a minimal reproducible example yet.

Please do try to come up with a recipe.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Geza Herman]

[-- Attachment #1.1: Type: text/plain, Size: 666 bytes --]


On 10/27/23 12:43, Eli Zaretskii wrote:

> Please do try to come up with a recipe.

Uncompress the attached file, and "emacs -Q x.txt"

Then, M-:, and insert this:

     (progn
       (setq scroll-conservatively 101)
       (font-lock-add-keywords nil '(((lambda (bound)) (1 'error prepend 
t))) t)
       (setq auto-hscroll-mode 'current-line)
       (setq truncate-lines t)
       (goto-char (point-max)))

Emacs will stop at line 19232 (point 3323065), but the file has 48263 lines.

As it turned out, this uses a rarely used configuration setting 
(auto-hscroll-mode set to current-line), so this issue is not a big deal 
I suppose.

[-- Attachment #1.2: Type: text/html, Size: 1223 bytes --]

[-- Attachment #2: x.txt.bz2 --]
[-- Type: application/octet-stream, Size: 4481 bytes --]

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

Ping!  Gregory, could you please look into this?

> Cc: Gregory Heytings <gregory@heytings.org>, 66764@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 09:50:33 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> OK, I think I see the root cause of the problem: it's your
> font-lock-keywords setting, viz.:
> 
>  (font-lock-add-keywords nil '(((lambda (bound)) (1 'error prepend t))) t)
> 
> Without this setting, everything works as expected, and goto-char goes
> to the EOB almost instantaneously, even when scroll-conservatively is
> set to a large value.
> 
> AFAIU, the font-lock-keywords setting above causes the display engine
> to call this function every time it moves across some chunk of text,
> which slows down redisplay.  This shows with scroll-conservatively set
> to a large value because Emacs then attempts to find the minimum
> amount of scrolling the screen in order to bring point into the view.
> 
> It is a known fact that modes which use advanced font-lock settings
> should adapt to the long-line situation (when the function
> long-line-optimizations-p returns non-nil), so I think you should
> modify your font-lock settings to avoid this problem in that case.
> 
> CC'ing Gregory in case I missed something in this scenario.
> 
> 
> 
> 

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

Ping! Ping!  Gregory, are you there?

> Cc: 66764@debbugs.gnu.org, geza.herman@gmail.com
> Date: Sat, 04 Nov 2023 10:29:49 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping!  Gregory, could you please look into this?
> 
> > Cc: Gregory Heytings <gregory@heytings.org>, 66764@debbugs.gnu.org
> > Date: Fri, 27 Oct 2023 09:50:33 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > OK, I think I see the root cause of the problem: it's your
> > font-lock-keywords setting, viz.:
> > 
> >  (font-lock-add-keywords nil '(((lambda (bound)) (1 'error prepend t))) t)
> > 
> > Without this setting, everything works as expected, and goto-char goes
> > to the EOB almost instantaneously, even when scroll-conservatively is
> > set to a large value.
> > 
> > AFAIU, the font-lock-keywords setting above causes the display engine
> > to call this function every time it moves across some chunk of text,
> > which slows down redisplay.  This shows with scroll-conservatively set
> > to a large value because Emacs then attempts to find the minimum
> > amount of scrolling the screen in order to bring point into the view.
> > 
> > It is a known fact that modes which use advanced font-lock settings
> > should adapt to the long-line situation (when the function
> > long-line-optimizations-p returns non-nil), so I think you should
> > modify your font-lock settings to avoid this problem in that case.
> > 
> > CC'ing Gregory in case I missed something in this scenario.
> > 
> > 
> > 
> > 
> 
> 
> 
> 

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Gregory Heytings]

>
> Ping! Ping!  Gregory, are you there?
>

Yes; I'll have a look.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 11:37:19 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: geza.herman@gmail.com, 66764@debbugs.gnu.org
> 
> > Ping! Ping!  Gregory, are you there?
> >
> 
> Yes; I'll have a look.

Any progress with this?

Thanks.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

Ping! Ping! Ping! Ping!  Gregory, I'd like to release Emacs 29.2 soon,
and I wonder whether we could/should fix this issue there?  Could you
please look into this soon?

> Cc: 66764@debbugs.gnu.org, geza.herman@gmail.com
> Date: Sat, 09 Dec 2023 15:33:52 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 25 Nov 2023 11:37:19 +0000
> > From: Gregory Heytings <gregory@heytings.org>
> > cc: geza.herman@gmail.com, 66764@debbugs.gnu.org
> > 
> > > Ping! Ping!  Gregory, are you there?
> > >
> > 
> > Yes; I'll have a look.
> 
> Any progress with this?
> 
> Thanks.
> 
> 
> 
> 

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Gregory Heytings]

>
> Ping! Ping! Ping! Ping!  Gregory, I'd like to release Emacs 29.2 soon, 
> and I wonder whether we could/should fix this issue there?  Could you 
> please look into this soon?
>

Sorry Eli, I've been overhwelmed by work at $job.  I will continue to work 
on this issue again in a few days, but most probably not before January 
6th.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Thu, 28 Dec 2023 10:53:34 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: geza.herman@gmail.com, 66764@debbugs.gnu.org
> 
> 
> >
> > Ping! Ping! Ping! Ping!  Gregory, I'd like to release Emacs 29.2 soon, 
> > and I wonder whether we could/should fix this issue there?  Could you 
> > please look into this soon?
> >
> 
> Sorry Eli, I've been overhwelmed by work at $job.  I will continue to work 
> on this issue again in a few days, but most probably not before January 
> 6th.

Did you have any chance to look at this?

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 86 bytes --]


>
> Did you have any chance to look at this?
>

Yes, finally, and here is the patch.

[-- Attachment #2: Fix-blunder-in-labeled_narrow_to_region.patch --]
[-- Type: text/x-diff, Size: 1083 bytes --]

From fb2c20bfffec757a1f707d4ab62c049ee7545c3a Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Thu, 11 Jan 2024 23:38:22 +0000
Subject: [PATCH] Fix blunder in labeled_narrow_to_region.

* src/editfns.c (labeled_narrow_to_region): Record point-marker
before, instead of after, calling narrow-to-region; otherwise
point has already changed.  Fixes bug#66764.
---
 src/editfns.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/editfns.c b/src/editfns.c
index 063dfc6d131..6ddee0840c2 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -2870,9 +2870,9 @@ unwind_labeled_narrow_to_region (Lisp_Object label)
 labeled_narrow_to_region (Lisp_Object begv, Lisp_Object zv,
 			  Lisp_Object label)
 {
-  Finternal__labeled_narrow_to_region (begv, zv, label);
   record_unwind_protect (restore_point_unwind, Fpoint_marker ());
   record_unwind_protect (unwind_labeled_narrow_to_region, label);
+  Finternal__labeled_narrow_to_region (begv, zv, label);
 }
 
 DEFUN ("widen", Fwiden, Swiden, 0, 0, "",
-- 
2.39.2

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Cc: 66764@debbugs.gnu.org, geza.herman@gmail.com
> Date: Tue, 09 Jan 2024 22:01:25 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 28 Dec 2023 10:53:34 +0000
> > From: Gregory Heytings <gregory@heytings.org>
> > cc: geza.herman@gmail.com, 66764@debbugs.gnu.org
> > 
> > > Ping! Ping! Ping! Ping!  Gregory, I'd like to release Emacs 29.2 soon, 
> > > and I wonder whether we could/should fix this issue there?  Could you 
> > > please look into this soon?
> > 
> > Sorry Eli, I've been overhwelmed by work at $job.  I will continue to work 
> > on this issue again in a few days, but most probably not before January 
> > 6th.
> 
> Did you have any chance to look at this?

Any chance of you looking into this in the next day or two?  If not, I
think Emacs 29.2 will be released with this issue unhandled.

TIA

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Thu, 11 Jan 2024 23:40:35 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 66764@debbugs.gnu.org, geza.herman@gmail.com
> 
> > Did you have any chance to look at this?
> 
> Yes, finally, and here is the patch.

Thanks, please install ASAP on the emacs-29 branch.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Cc: geza.herman@gmail.com, 66764@debbugs.gnu.org
> Date: Sat, 13 Jan 2024 21:10:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Any chance of you looking into this in the next day or two?  If not, I
> think Emacs 29.2 will be released with this issue unhandled.

Sorry, please ignore the above.  I somehow failed to pay attention
that you already posted a patch for this issue.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Cc: geza.herman@gmail.com, 66764@debbugs.gnu.org
> Date: Sat, 13 Jan 2024 21:11:53 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 11 Jan 2024 23:40:35 +0000
> > From: Gregory Heytings <gregory@heytings.org>
> > cc: 66764@debbugs.gnu.org, geza.herman@gmail.com
> > 
> > > Did you have any chance to look at this?
> > 
> > Yes, finally, and here is the patch.
> 
> Thanks, please install ASAP on the emacs-29 branch.

Gregory, are there any considerations that preclude installing this
patch at this time?  If it's just your free time, I can install it for
you.

Thanks.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Gregory Heytings]

>
> Gregory, are there any considerations that preclude installing this 
> patch at this time?  If it's just your free time, I can install it for 
> you.
>

I was AFK between the moment your previous post arrived and now.  Just 
done (5bb5590dec).

Is there any chance the (cosmetic) change in 9e9e11648d could be 
cherry-picked from master to emacs-29?  I had forgotten they were only on 
master, and my eyes were hurting when I read that part of the code while 
debugging it.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Eli Zaretskii]

> Date: Sun, 14 Jan 2024 22:06:30 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 66764@debbugs.gnu.org, geza.herman@gmail.com
> 
> > Gregory, are there any considerations that preclude installing this 
> > patch at this time?  If it's just your free time, I can install it for 
> > you.
> 
> I was AFK between the moment your previous post arrived and now.  Just 
> done (5bb5590dec).

Thanks.  Should we now close this bug?

> Is there any chance the (cosmetic) change in 9e9e11648d could be 
> cherry-picked from master to emacs-29?  I had forgotten they were only on 
> master, and my eyes were hurting when I read that part of the code while 
> debugging it.

Yes, okay.

bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping

[Gregory Heytings]

>> I was AFK between the moment your previous post arrived and now.  Just 
>> done (5bb5590dec).
>
> Thanks.  Should we now close this bug?
>

Yes, I don't think there's anything more to do here.

>> Is there any chance the (cosmetic) change in 9e9e11648d could be 
>> cherry-picked from master to emacs-29?  I had forgotten they were only 
>> on master, and my eyes were hurting when I read that part of the code 
>> while debugging it.
>
> Yes, okay.
>

Thanks, done (53b5b77010).