bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5998: 23.1.96; Breadcrumbs defeat C-u 1 C-v in Info


From: Eli Zaretskii
Subject: bug#5998: 23.1.96; Breadcrumbs defeat C-u 1 C-v in Info
Date: Tue, 06 Sep 2016 18:02:05 +0300

> From: Juri Linkov <juri@linkov.net>
> Cc: Andrew Hyatt <ahyatt@gmail.com>,  5998@debbugs.gnu.org,  
> drew.adams@oracle.com
> Date: Mon, 05 Sep 2016 22:28:18 +0300
> 
> > (But the original problem with
> > scrolling a window that starts with invisible text followed by an
> > overlay with an after-string -- that problem still exists.)
> 
> Or there is no bug at all: with invisible text followed by an overlay
> with an after-string you can't put point to the beginning of the Info
> buffer - probably for a reason.  OTOH, using more reasonable ‘display’
> allows point to move to the top of the window, so perhaps this is why
> scrolling works in the latter case but doesn't work in the former one.

The actual problem is that an "empty" overlay (i.e. overlay that hides
no buffer positions) with a before-string or after-string at the
beginning of the window exposes a flaw in the method the Emacs display
engine determines a window-start position: it is specified by a buffer
position.  That makes the actual window-start on display ambiguous,
since both the overlay string and the buffer position after it have
the same value.  If the string also includes a newline, it defeats the
algorithm for scrolling a window by N lines, which just goes to the
window-start point, and then moves forward/back by those N lines.  In
particular, if N = 1, the buffer position after the move is unchanged,
and the scroll will appear to have not happened.

I have a working patch for fixing this, but it sometimes requires to
invoke the scroll command twice, so I'm trying to find a better fix.
If I won't find it, I will commit what I have, because it's an
improvement.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]