GNU bug report logs - #72323
31.0.50; line-move unconditionally resets vscroll to 0

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Mon, 19 Aug 2024 14:06:52 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sun, 18 Aug 2024 15:17:48 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > I disagree.  When point moves to another screen line without moving
> >> > window-start, vscroll may or may not be valid.  Whether it is depends
> >> > on the details of what is on display.
> >> 
> >> Can you give me an example example where moving point invalidates
> >> vscroll (except when point would move partially or fully off screen)?
> >
> > Why isn't the one example I gave enough?
> >
> > The code in question doesn't know whether this is or isn't the case,
> > at least not in all cases and not without a lot of tedious layout
> > calculations.  Whether the current line will be fully visible is only
> > known after the window is redisplayed.  At which time we also check
> > that we didn't enter the scroll margins and other conditions that
> > require to scroll the window.  Keeping the vscroll would make all this
> > much more complicated, so we play it safe.
> 
> I just wanted to confirm that the issue is specifically about the being
> fully visible and not something else I'm missing. If that's the case,
> I'll see if I can hack something up for my own use and, if usable, see
> if it's possible to integrate into pixel-scroll-precision-mode. But
> it'll have to be an advice as line-move is called all over the place.

That was the first thing on my mind.  It might be the only one, but I
cannot guarantee that: the Emacs display and display-related
capabilities are almost infinite in the features and combinations of
features they are expected to support; I'm hacking this code for the
last 20 years, and still learn new aspects every now and then.

> It really sounds like you just don't want to mess with this function
> which is a reasonable stance as the maintainer.

That's right: I spent so many hours debugging and fixing it in various
tricky situations that I very much dislike the idea of removing one of
its main assumptions which was there since before my time.  Please
keep in mind that it isn't just this function that resets vscroll, the
same is done under certain conditions by the display code in C as
well.  So if we are going to change that, we may need to make
corresponding changes there also.

> But it was really hard to tell if there was something I was
> fundamentally misunderstanding or if you were just being cautious
> and not wanting to touch a complex piece of machinery if it's
> working "well enough".

It's mainly the latter.  But I have a lot of gray hair to back that
up.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.