unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
@ 2023-10-26 17:04 Geza Herman
  2023-10-26 18:25 ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Geza Herman @ 2023-10-26 17:04 UTC (permalink / raw)
  To: 66764

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






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-26 17:04 bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping Geza Herman
@ 2023-10-26 18:25 ` Eli Zaretskii
  2023-10-26 19:12   ` Herman, Géza
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-26 18:25 UTC (permalink / raw)
  To: Geza Herman; +Cc: 66764

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-26 18:25 ` Eli Zaretskii
@ 2023-10-26 19:12   ` Herman, Géza
  2023-10-27  5:46     ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Herman, Géza @ 2023-10-26 19:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66764



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.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-26 19:12   ` Herman, Géza
@ 2023-10-27  5:46     ` Eli Zaretskii
  2023-10-27  6:50       ` Eli Zaretskii
  2023-10-27  9:22       ` Herman, Géza
  0 siblings, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-27  5:46 UTC (permalink / raw)
  To: Herman Géza; +Cc: 66764

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-27  5:46     ` Eli Zaretskii
@ 2023-10-27  6:50       ` Eli Zaretskii
  2023-10-27  9:43         ` Herman, Géza
  2023-11-04  8:29         ` Eli Zaretskii
  2023-10-27  9:22       ` Herman, Géza
  1 sibling, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-27  6:50 UTC (permalink / raw)
  To: geza.herman; +Cc: Gregory Heytings, 66764

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.





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-27  5:46     ` Eli Zaretskii
  2023-10-27  6:50       ` Eli Zaretskii
@ 2023-10-27  9:22       ` Herman, Géza
  2023-10-27 10:43         ` Eli Zaretskii
  1 sibling, 1 reply; 12+ messages in thread
From: Herman, Géza @ 2023-10-27  9:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66764



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.







^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-27  6:50       ` Eli Zaretskii
@ 2023-10-27  9:43         ` Herman, Géza
  2023-11-04  8:29         ` Eli Zaretskii
  1 sibling, 0 replies; 12+ messages in thread
From: Herman, Géza @ 2023-10-27  9:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Gregory Heytings, 66764



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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-27  9:22       ` Herman, Géza
@ 2023-10-27 10:43         ` Eli Zaretskii
  2023-10-28  1:15           ` Geza Herman
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-27 10:43 UTC (permalink / raw)
  To: Herman Géza; +Cc: 66764

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-27 10:43         ` Eli Zaretskii
@ 2023-10-28  1:15           ` Geza Herman
  0 siblings, 0 replies; 12+ messages in thread
From: Geza Herman @ 2023-10-28  1:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66764


[-- 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 --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-10-27  6:50       ` Eli Zaretskii
  2023-10-27  9:43         ` Herman, Géza
@ 2023-11-04  8:29         ` Eli Zaretskii
  2023-11-18  9:01           ` Eli Zaretskii
  1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-11-04  8:29 UTC (permalink / raw)
  To: gregory; +Cc: 66764, geza.herman

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





^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-11-04  8:29         ` Eli Zaretskii
@ 2023-11-18  9:01           ` Eli Zaretskii
  2023-11-25 11:37             ` Gregory Heytings
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-11-18  9:01 UTC (permalink / raw)
  To: gregory; +Cc: geza.herman, 66764

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






^ permalink raw reply	[flat|nested] 12+ messages in thread

* bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
  2023-11-18  9:01           ` Eli Zaretskii
@ 2023-11-25 11:37             ` Gregory Heytings
  0 siblings, 0 replies; 12+ messages in thread
From: Gregory Heytings @ 2023-11-25 11:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66764, geza.herman


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

Yes; I'll have a look.






^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2023-11-25 11:37 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-26 17:04 bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping Geza Herman
2023-10-26 18:25 ` Eli Zaretskii
2023-10-26 19:12   ` Herman, Géza
2023-10-27  5:46     ` Eli Zaretskii
2023-10-27  6:50       ` Eli Zaretskii
2023-10-27  9:43         ` Herman, Géza
2023-11-04  8:29         ` Eli Zaretskii
2023-11-18  9:01           ` Eli Zaretskii
2023-11-25 11:37             ` Gregory Heytings
2023-10-27  9:22       ` Herman, Géza
2023-10-27 10:43         ` Eli Zaretskii
2023-10-28  1:15           ` Geza Herman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).