unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Herman Géza" <geza.herman@gmail.com>
Cc: 66764@debbugs.gnu.org
Subject: bug#66764: 29.1; Emacs scrolls for "(goto-char (point-max))" instead of jumping
Date: Fri, 27 Oct 2023 08:46:14 +0300	[thread overview]
Message-ID: <83a5s4fwih.fsf@gnu.org> (raw)
In-Reply-To: <807a1bd5-6477-cc36-088f-efcb782ccb99@gmail.com> (message from Herman, Géza on Thu, 26 Oct 2023 21:12:55 +0200)

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





  reply	other threads:[~2023-10-27  5:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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-12-09 13:33               ` Eli Zaretskii
2023-12-23  8:37                 ` Eli Zaretskii
2023-12-28 10:53                   ` Gregory Heytings
2024-01-09 20:01                     ` Eli Zaretskii
2024-01-11 23:40                       ` Gregory Heytings
2024-01-13 19:11                         ` Eli Zaretskii
2024-01-14 19:36                           ` Eli Zaretskii
2024-01-14 22:06                             ` Gregory Heytings
2024-01-15 12:22                               ` Eli Zaretskii
2024-01-15 13:30                                 ` Gregory Heytings
2024-01-13 19:10                       ` Eli Zaretskii
2024-01-13 19:13                         ` Eli Zaretskii
2023-10-27  9:22       ` Herman, Géza
2023-10-27 10:43         ` Eli Zaretskii
2023-10-28  1:15           ` Geza Herman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a5s4fwih.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=66764@debbugs.gnu.org \
    --cc=geza.herman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).