bug#8355: 24.0.50; Boxes in mode-line and scrolling

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

(follow-up to http://article.gmane.org/gmane.emacs.devel/137753 , where
I was asked to report this here)

There seems to be a conflict between scrolling and the box attribute in
mode-line. I have in my config a ":box t" attribute in mode-line (from
the theme I use, zenburn.el). With this setting on, C-v M-v produces a
net displacement of one line up, which is annoying. This seems to be
irrespective of settings such as scroll-conservatively or
scroll-preserve-screen-position.

I'm not 100% sure how to reproduce this, as I use the color-theme
package to set the parameter. Any way to set the mode-line :box
attribute to "t" will trigger it. Then, find a sufficiently large file,
and do C-v M-v.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> There seems to be a conflict between scrolling and the box attribute in
> mode-line. I have in my config a ":box t" attribute in mode-line (from
> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
> net displacement of one line up, which is annoying. This seems to be
> irrespective of settings such as scroll-conservatively or
> scroll-preserve-screen-position.
>
> I'm not 100% sure how to reproduce this, as I use the color-theme
> package to set the parameter. Any way to set the mode-line :box
> attribute to "t" will trigger it. Then, find a sufficiently large file,
> and do C-v M-v.

(This bug report unfortunately got no response at the time.)

Are you still seeing this in more recent versions of Emacs?  If so,
could you try to come up with a step-by-step recipe to reproduce it,
starting from "emacs -Q"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

Oof that's old.

The original bug might have been at least partially closed, I now don't
see this as much as I used to in code buffers (but it might equally have
been a change in my config). However I do see this *a lot* in tex files,
reproductibly, and it's still very annoying. I'd love it if this was
fixed!

Here's a reproducer from emacs -Q (just reproduced on 27.1):

Set
(setq scroll-conservatively 100000000)
(setq scroll-preserve-screen-position 'stay)

Open a latex file of some complexity (with sections and math, for
instance https://arxiv.org/e-print/2003.00726, but it works on any tex
file), and make sure it's in latex-mode. Go somewhere in the middle of
the file, center point (C-l), then scroll up then down (C-v and M-v).



I traced it down to
lines of varying heights: it disappears if I set
(setq font-latex-fontify-script nil)
(setq font-latex-fontify-sectioning 'color)

Best,
Antoine

08 December 2020 16:05 +01, Lars Ingebrigtsen:
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> There seems to be a conflict between scrolling and the box attribute in
>> mode-line. I have in my config a ":box t" attribute in mode-line (from
>> the theme I use, zenburn.el). With this setting on, C-v M-v produces a
>> net displacement of one line up, which is annoying. This seems to be
>> irrespective of settings such as scroll-conservatively or
>> scroll-preserve-screen-position.
>>
>> I'm not 100% sure how to reproduce this, as I use the color-theme
>> package to set the parameter. Any way to set the mode-line :box
>> attribute to "t" will trigger it. Then, find a sufficiently large file,
>> and do C-v M-v.
>
> (This bug report unfortunately got no response at the time.)
>
> Are you still seeing this in more recent versions of Emacs?  If so,
> could you try to come up with a step-by-step recipe to reproduce it,
> starting from "emacs -Q"?

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Here's a reproducer from emacs -Q (just reproduced on 27.1):
>
> Set
> (setq scroll-conservatively 100000000)
> (setq scroll-preserve-screen-position 'stay)
>
> Open a latex file of some complexity (with sections and math, for
> instance https://arxiv.org/e-print/2003.00726, but it works on any tex
> file), and make sure it's in latex-mode. Go somewhere in the middle of
> the file, center point (C-l), then scroll up then down (C-v and M-v).

Yup; I can reproduce this in Emacs 28 -- point moves around a lot when
paging back and forth.

> I traced it down to
> lines of varying heights: it disappears if I set
> (setq font-latex-fontify-script nil)
> (setq font-latex-fontify-sectioning 'color)

Yes, I guess this is due to the mixture of line heights in that
buffer -- when it's computing how many lines to scroll back and forth,
it's not being consistent when going forward and backward.

Eli, does this sound familiar to you?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 8355@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 08 Dec 2020 19:18:12 +0100
> 
> Antoine Levitt <antoine.levitt@gmail.com> writes:
> 
> > Here's a reproducer from emacs -Q (just reproduced on 27.1):
> >
> > Set
> > (setq scroll-conservatively 100000000)
> > (setq scroll-preserve-screen-position 'stay)
> >
> > Open a latex file of some complexity (with sections and math, for
> > instance https://arxiv.org/e-print/2003.00726, but it works on any tex
> > file), and make sure it's in latex-mode. Go somewhere in the middle of
> > the file, center point (C-l), then scroll up then down (C-v and M-v).
> 
> Yup; I can reproduce this in Emacs 28 -- point moves around a lot when
> paging back and forth.

I wouldn't say "a lot".  On my system it moves by less than a screen
line.

> > I traced it down to
> > lines of varying heights: it disappears if I set
> > (setq font-latex-fontify-script nil)
> > (setq font-latex-fontify-sectioning 'color)
> 
> Yes, I guess this is due to the mixture of line heights in that
> buffer -- when it's computing how many lines to scroll back and forth,
> it's not being consistent when going forward and backward.
> 
> Eli, does this sound familiar to you?

Not really.  I will look into it, in case there's some off-by-one, but
you are probably right about the reason.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Date: Tue, 08 Dec 2020 16:56:50 +0100
> Cc: 8355@debbugs.gnu.org
> 
> The original bug might have been at least partially closed, I now don't
> see this as much as I used to in code buffers (but it might equally have
> been a change in my config). However I do see this *a lot* in tex files,
> reproductibly, and it's still very annoying. I'd love it if this was
> fixed!
> 
> Here's a reproducer from emacs -Q (just reproduced on 27.1):
> 
> Set
> (setq scroll-conservatively 100000000)
> (setq scroll-preserve-screen-position 'stay)
> 
> Open a latex file of some complexity (with sections and math, for
> instance https://arxiv.org/e-print/2003.00726, but it works on any tex
> file), and make sure it's in latex-mode. Go somewhere in the middle of
> the file, center point (C-l), then scroll up then down (C-v and M-v).
> 
> 
> 
> I traced it down to
> lines of varying heights: it disappears if I set
> (setq font-latex-fontify-script nil)
> (setq font-latex-fontify-sectioning 'color)

I don't think I understand what is the complaint here.  The screen
position of the cursor _is_ preserved with these settings, don't you
agree?  They are preserved on my system: I did many C-v and M-v, and
the cursor stays on the same spot on display, moving a few pixels here
and there when the line at cursor is smaller or taller than the
default.

If this is what you see, then what is NOT working as expected in this
scenario?

The original report was talking about C-v followed by M-v producing a
1-line displacement.  Is _that_ the problem?  If so, why did you
expect Emacs to come to the same place, AFAIK there's no guarantee of
that when variable-height text is involved.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand what is the complaint here.  The screen
> position of the cursor _is_ preserved with these settings, don't you
> agree?  They are preserved on my system: I did many C-v and M-v, and
> the cursor stays on the same spot on display, moving a few pixels here
> and there when the line at cursor is smaller or taller than the
> default.
>
> If this is what you see, then what is NOT working as expected in this
> scenario?

I think the bug reporter means the inconsistent behaviour of point.

Start with:


[-- Attachment #2: Type: image/png, Size: 180801 bytes --]

[-- Attachment #3: Type: text/plain, Size: 24 bytes --]


And then M-v and C-v:


[-- Attachment #4: Type: image/png, Size: 187719 bytes --]

[-- Attachment #5: Type: text/plain, Size: 518 bytes --]


Note how we landed on the line over where we started.

> The original report was talking about C-v followed by M-v producing a
> 1-line displacement.  Is _that_ the problem?  If so, why did you
> expect Emacs to come to the same place, AFAIK there's no guarantee of
> that when variable-height text is involved.

Shouldn't there be?  Going back a page and forward a page should ideally
land you on the same line.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Antoine Levitt <antoine.levitt@gmail.com>,  8355@debbugs.gnu.org
> Date: Tue, 08 Dec 2020 19:27:12 +0100
> 
> > The original report was talking about C-v followed by M-v producing a
> > 1-line displacement.  Is _that_ the problem?  If so, why did you
> > expect Emacs to come to the same place, AFAIK there's no guarantee of
> > that when variable-height text is involved.
> 
> Shouldn't there be?  Going back a page and forward a page should ideally
> land you on the same line.

That's not how Emacs scroll commands work.  But as I said, I will look
closer at the code and see if there's some subtle issue here.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> Date: Tue, 08 Dec 2020 20:33:24 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: antoine.levitt@gmail.com, 8355@debbugs.gnu.org
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Antoine Levitt <antoine.levitt@gmail.com>,  8355@debbugs.gnu.org
> > Date: Tue, 08 Dec 2020 19:27:12 +0100
> > 
> > > The original report was talking about C-v followed by M-v producing a
> > > 1-line displacement.  Is _that_ the problem?  If so, why did you
> > > expect Emacs to come to the same place, AFAIK there's no guarantee of
> > > that when variable-height text is involved.
> > 
> > Shouldn't there be?  Going back a page and forward a page should ideally
> > land you on the same line.
> 
> That's not how Emacs scroll commands work.  But as I said, I will look
> closer at the code and see if there's some subtle issue here.

I installed a partial fix for this.  It improves the situation, in
that for many starting positions of point, the sequence of N C-v's
followed by N M-v's, or vice versa, will now end up in the same line
and the same screen position.  There are still cases where we end up
short by one line, and I don't see how that could be fixed as long as
the buffer has some stretches of lines with smaller or larger height.

Please try the latest master; if the improvement is sufficient, we can
close this bug.

Thanks.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I installed a partial fix for this.  It improves the situation, in
> that for many starting positions of point, the sequence of N C-v's
> followed by N M-v's, or vice versa, will now end up in the same line
> and the same screen position.  There are still cases where we end up
> short by one line, and I don't see how that could be fixed as long as
> the buffer has some stretches of lines with smaller or larger height.
>
> Please try the latest master; if the improvement is sufficient, we can
> close this bug.

I tried it now, and it's a lot more consistent now than it was before.
Before it was almost always off by one line, but now it's correct most
of the time.

I tried this on something that has more dramatic line height
differences, and the phenomenon is more noticeable there -- when
scrolling downwards, things are very predictable, but when scrolling
backwards, Emacs seems to decide to scroll a couple of screenfuls when
there's large images in the buffer, and you have to C-v twice to get
back to where you were.

Should I make a test case?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: antoine.levitt@gmail.com,  8355@debbugs.gnu.org
> Date: Wed, 09 Dec 2020 18:01:44 +0100
> 
> I tried this on something that has more dramatic line height
> differences, and the phenomenon is more noticeable there -- when
> scrolling downwards, things are very predictable, but when scrolling
> backwards, Emacs seems to decide to scroll a couple of screenfuls when
> there's large images in the buffer, and you have to C-v twice to get
> back to where you were.
> 
> Should I make a test case?

Yes, please.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, please.

This one should illustrate the problem, I think:

(defun make-buffer ()
  (switch-to-buffer "*images*")
  (erase-buffer)
  (let ((height (* (frame-pixel-height) 0.6))
	(width (* (frame-pixel-width) 0.7)))
    (dotimes (i 10)
      (let ((svg (svg-create width height)))
	(svg-rectangle svg 0 0 width height
		       :fill (format "#%02x%02x%02x"
				     (random 255)
				     (random 255)
				     (random 255)))
	(svg-text svg (format "Image %d" i)
		  :font-size 50
		  :fill "black"
		  :font-weight "bold"
		  :x (/ width 2)
		  :y (/ height 2)
		  :text-anchor "middle")
	(insert-image (svg-image svg :scale 1))
	(insert (format "\n\nImage %d\n\n" i))))))

Scroll downwards to the test "Image 4", for instance.  This is what I
have in my window then:


[-- Attachment #2: Type: image/png, Size: 36305 bytes --]

[-- Attachment #3: Type: text/plain, Size: 95 bytes --]


So we see the entirety of Image 4, and the top of Image 5, and that's
fine.  Then hit `M-v':


[-- Attachment #4: Type: image/png, Size: 38280 bytes --]

[-- Attachment #5: Type: text/plain, Size: 171 bytes --]


We see the entirety of image 2, and the top of image 3, which seems like
we've overshot -- I'd expect to see the entirety of image 3, and the top
of image 4.

Then C-v:


[-- Attachment #6: Type: image/png, Size: 36600 bytes --]

[-- Attachment #7: Type: text/plain, Size: 400 bytes --]


We're not back to where we started, but instead have the entirety of
image 3, and the top of image 4 (which is what I'd expect when C-v-ing
from where I was).

So I think Emacs behaves very nicely when C-v-ing down a buffer of large
images, but when M-v-ing back up, it seems to scroll too far.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

09 December 2020 18:24 +01, Lars Ingebrigtsen:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Yes, please.
>
> This one should illustrate the problem, I think:

Thanks Eli for doing this! Trying out in tex files (same reproducer as
before), it does seem to be a bit better than previously in that I
sometimes see no movement when doing C-v M-v, and generally movement
when it occurs seems to be reduced (ie one line at a time rather than
several), but movement does remain the rule and no movement the
exception. This is even with the default settings for latex, which
results in very moderate line height discrepancies: on a random tex file
on my computer, (line-pixel-height) says normal lines are 18 pixels,
with the ones having subscripts and superscripts being 19 pixels.
Although I often have a lot of subscripts and superscripts, so it's
possible there's more than 9 lines that are 19 pixels tall on my screen,
if that's what matters.

Best,
Antoine

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 8355@debbugs.gnu.org
> Date: Wed, 09 Dec 2020 21:47:48 +0100
> 
> movement does remain the rule and no movement the exception.

IME, with that file and the default settings, it's the other way
around.

If the changes I installed don't improve things considerably, perhaps
I should revert them?

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

10 December 2020 04:34 +01, Eli Zaretskii:
>> From: Antoine Levitt <antoine.levitt@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 8355@debbugs.gnu.org
>> Date: Wed, 09 Dec 2020 21:47:48 +0100
>> 
>> movement does remain the rule and no movement the exception.
>
> IME, with that file and the default settings, it's the other way
> around.
>
> If the changes I installed don't improve things considerably, perhaps
> I should revert them?

It's still better than the previous behavior so I would keep it. But the
question is what is the correct thing to do. 

I know nothing about how it's implemented, but I would assume a simple
round-to-nearest should do the trick, at least a very high fraction of
the time? So you've got a set of integers (the pixel positions of the
line), a current integer (the current line) and you want to move to
another integer in the set, approximately by some prescribed amount n
(the screen height). If you do the simplest thing which is to move by n
and round to the nearest line, then if you go down once and up once the
only way you can fail to come back to the original point is if the shift
you applied to round to a line is larger than the half-separation
between lines. So if I have lines of about 20px, I would expect that to
happen maybe 10% of the time; and I would also expect that sometimes the
line shift is up and sometimes down. But in my tests, even with your
patch, I see it happening a lot more than 10%, and always in the same
direction (going down then up shifts one line up). So either it's
something to do with the pixel distribution of my tex files which is
messing this up, or I misunderstand the algorithm.

Best,
Antoine

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Cc: larsi@gnus.org, 8355@debbugs.gnu.org
> Date: Fri, 11 Dec 2020 09:35:20 +0100
> 
> > If the changes I installed don't improve things considerably, perhaps
> > I should revert them?
> 
> It's still better than the previous behavior so I would keep it. But the
> question is what is the correct thing to do. 

OK, thanks.

> I know nothing about how it's implemented, but I would assume a simple
> round-to-nearest should do the trick, at least a very high fraction of
> the time?

That's what I did, or at least I thought I did.

> So you've got a set of integers (the pixel positions of the
> line), a current integer (the current line) and you want to move to
> another integer in the set, approximately by some prescribed amount n
> (the screen height). If you do the simplest thing which is to move by n
> and round to the nearest line, then if you go down once and up once the
> only way you can fail to come back to the original point is if the shift
> you applied to round to a line is larger than the half-separation
> between lines. So if I have lines of about 20px, I would expect that to
> happen maybe 10% of the time; and I would also expect that sometimes the
> line shift is up and sometimes down. But in my tests, even with your
> patch, I see it happening a lot more than 10%, and always in the same
> direction (going down then up shifts one line up). So either it's
> something to do with the pixel distribution of my tex files which is
> messing this up, or I misunderstand the algorithm.

A reproduction recipe for where you see this happening more that will
be appreciated.

I also don't understand how you arrived at the 10% figure.  Can you
elaborate?

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

11 December 2020 09:47 +01, Eli Zaretskii:
>> So you've got a set of integers (the pixel positions of the
>> line), a current integer (the current line) and you want to move to
>> another integer in the set, approximately by some prescribed amount n
>> (the screen height). If you do the simplest thing which is to move by n
>> and round to the nearest line, then if you go down once and up once the
>> only way you can fail to come back to the original point is if the shift
>> you applied to round to a line is larger than the half-separation
>> between lines. So if I have lines of about 20px, I would expect that to
>> happen maybe 10% of the time; and I would also expect that sometimes the
>> line shift is up and sometimes down. But in my tests, even with your
>> patch, I see it happening a lot more than 10%, and always in the same
>> direction (going down then up shifts one line up). So either it's
>> something to do with the pixel distribution of my tex files which is
>> messing this up, or I misunderstand the algorithm.
>
> A reproduction recipe for where you see this happening more that will
> be appreciated.

OK, I'll try it out more; I'm not running master "in production" yet
because of some issue with mu4e not limiting the mail it shows me that I
haven't had time to debug yet.

> I also don't understand how you arrived at the 10% figure.  Can you
> elaborate?

I assumed small, random variations in height of amplitude δh around a
reference height h0, and n δh >> h0. Then the place where you fall
before rounding is randomly distributed. You'll get movement only if
you've rounded up or down by about the half-separation, which should
happen a fraction 1/pixel height of the time. I have lines about 20px
tall, so that's 5%; I multiply by two to account for the possibility of
having rounded both up and down. If anything this should be an
overestimate; but again my assumptions are probably unrealistic (eg for
instance in my tex files the δh is always positive, which might explain
why I always see movement in the same direction).

Best,
Antoine

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Cc: larsi@gnus.org, 8355@debbugs.gnu.org
> Date: Fri, 11 Dec 2020 10:08:03 +0100
> 
> > A reproduction recipe for where you see this happening more that will
> > be appreciated.
> 
> OK, I'll try it out more

Thanks in advance.

> > I also don't understand how you arrived at the 10% figure.  Can you
> > elaborate?
> 
> I assumed small, random variations in height of amplitude δh around a
> reference height h0, and n δh >> h0. Then the place where you fall
> before rounding is randomly distributed. You'll get movement only if
> you've rounded up or down by about the half-separation, which should
> happen a fraction 1/pixel height of the time. I have lines about 20px
> tall, so that's 5%; I multiply by two to account for the possibility of
> having rounded both up and down. If anything this should be an
> overestimate; but again my assumptions are probably unrealistic (eg for
> instance in my tex files the δh is always positive, which might explain
> why I always see movement in the same direction).

You assume random distribution of taller or smaller lines through the
document, but that is not necessarily true.  There could be large
groups of smaller or taller lines, which will skew the percentage.

Anyway, an example where this happens will be useful to at least
understand what's going on, and perhaps provide a better solution.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

11 December 2020 12:59 +01, Eli Zaretskii:
>> I assumed small, random variations in height of amplitude δh around a
>> reference height h0, and n δh >> h0. Then the place where you fall
>> before rounding is randomly distributed. You'll get movement only if
>> you've rounded up or down by about the half-separation, which should
>> happen a fraction 1/pixel height of the time. I have lines about 20px
>> tall, so that's 5%; I multiply by two to account for the possibility of
>> having rounded both up and down. If anything this should be an
>> overestimate; but again my assumptions are probably unrealistic (eg for
>> instance in my tex files the δh is always positive, which might explain
>> why I always see movement in the same direction).
>
> You assume random distribution of taller or smaller lines through the
> document, but that is not necessarily true.  There could be large
> groups of smaller or taller lines, which will skew the percentage.
>
> Anyway, an example where this happens will be useful to at least
> understand what's going on, and perhaps provide a better solution.

I completely agree my assumptions are unrealistic, it was just to
get a baseline for what to expect.

So, on the tex file from arxiv I posted
(https://arxiv.org/e-print/2003.00726), I tried the following: from
emacs -Q with

(setq scroll-conservatively 100000000)
(setq scroll-preserve-screen-position 'stay)

go to a random line, C-l, C-v, M-v, see if the cursor moved. I did a
macro with that, and repeating it I'm able to get eg from line 368 to
line 305. Most lines are 18px, some 19. My screen is about 30 lines
tall, so the fact this phenomenon appears for ~65 contiguous lines (ie
more than two screenfuls) suggests that it's more than just bad luck.
For reproducibility, I'm using stock GTK emacs -Q on a 1366x768 screen
with Monospace Regular 11 font in fullscreen.

Best,
Antoine

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Cc: larsi@gnus.org, 8355@debbugs.gnu.org
> Date: Fri, 11 Dec 2020 13:25:16 +0100
> 
> So, on the tex file from arxiv I posted
> (https://arxiv.org/e-print/2003.00726), I tried the following: from
> emacs -Q with
> 
> (setq scroll-conservatively 100000000)
> (setq scroll-preserve-screen-position 'stay)
> 
> go to a random line, C-l, C-v, M-v, see if the cursor moved. I did a
> macro with that, and repeating it I'm able to get eg from line 368 to
> line 305. Most lines are 18px, some 19. My screen is about 30 lines
> tall, so the fact this phenomenon appears for ~65 contiguous lines (ie
> more than two screenfuls) suggests that it's more than just bad luck.
> For reproducibility, I'm using stock GTK emacs -Q on a 1366x768 screen
> with Monospace Regular 11 font in fullscreen.

Thanks, please try the latest master branch.  I hope I improved the
situation some more.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Antoine Levitt]

14 December 2020 19:25 +01, Eli Zaretskii:
> Thanks, please try the latest master branch.  I hope I improved the
> situation some more.

Oh wow, that's awesome! I'll try it out some more but it seems that the
problem is mostly gone (ie it still happens sometimes, but pretty
rarely). To find places where it happens, I use the macro C-n C-l C-v
M-v and repeated it. It looks roughly consistent with my 10% heuristic,
so I would say this bug is fixed: I imagine "fixing" it completely would
change semantics too much and might not be generally desirable. If I
want to really impose this behavior I can always tweak C-v and M-v to
scroll by a fixed amount of lines.

Thanks a lot Eli for the fix, and thanks Lars for taking up this old bug
report!

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Antoine Levitt <antoine.levitt@gmail.com>
> Cc: larsi@gnus.org, 8355@debbugs.gnu.org
> Date: Mon, 14 Dec 2020 20:02:22 +0100
> 
> 14 December 2020 19:25 +01, Eli Zaretskii:
> > Thanks, please try the latest master branch.  I hope I improved the
> > situation some more.
> 
> Oh wow, that's awesome! I'll try it out some more but it seems that the
> problem is mostly gone (ie it still happens sometimes, but pretty
> rarely).

AFAICT, it generally happens when you have a continued line around the
place where the new window-start should be.  Then Emacs will move
window-start one or more screen lines to start after a newline, and
you have a mismatch going back.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: antoine.levitt@gmail.com,  8355@debbugs.gnu.org
> Date: Wed, 09 Dec 2020 18:24:35 +0100
> 
> (defun make-buffer ()
>   (switch-to-buffer "*images*")
>   (erase-buffer)
>   (let ((height (* (frame-pixel-height) 0.6))
> 	(width (* (frame-pixel-width) 0.7)))
>     (dotimes (i 10)
>       (let ((svg (svg-create width height)))
> 	(svg-rectangle svg 0 0 width height
> 		       :fill (format "#%02x%02x%02x"
> 				     (random 255)
> 				     (random 255)
> 				     (random 255)))
> 	(svg-text svg (format "Image %d" i)
> 		  :font-size 50
> 		  :fill "black"
> 		  :font-weight "bold"
> 		  :x (/ width 2)
> 		  :y (/ height 2)
> 		  :text-anchor "middle")
> 	(insert-image (svg-image svg :scale 1))
> 	(insert (format "\n\nImage %d\n\n" i))))))
> 
> Scroll downwards to the test "Image 4", for instance.  This is what I
> have in my window then:
> 
> So we see the entirety of Image 4, and the top of Image 5, and that's
> fine.  Then hit `M-v':
> 
> We see the entirety of image 2, and the top of image 3, which seems like
> we've overshot -- I'd expect to see the entirety of image 3, and the top
> of image 4.
> 
> Then C-v:
> 
> We're not back to where we started, but instead have the entirety of
> image 3, and the top of image 4 (which is what I'd expect when C-v-ing
> from where I was).
> 
> So I think Emacs behaves very nicely when C-v-ing down a buffer of large
> images, but when M-v-ing back up, it seems to scroll too far.

Thanks, this should now be fixed on the master branch.

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, this should now be fixed on the master branch.

Wonderful!  Seems to work perfectly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: antoine.levitt@gmail.com,  8355@debbugs.gnu.org
> Date: Mon, 14 Dec 2020 20:05:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, this should now be fixed on the master branch.
> 
> Wonderful!  Seems to work perfectly.

The scary thing about this fix is that the problematic code was in a
very low-level function, which is used all over the place, and that
code didn't change since Emacs 21.  So I wonder/dread what other
effects will this change have...

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The scary thing about this fix is that the problematic code was in a
> very low-level function, which is used all over the place, and that
> code didn't change since Emacs 21.  So I wonder/dread what other
> effects will this change have...

It's exciting.  :-)  I've used the new version for some hours now, and
in buffers with/without odd font combinations/images, and navigation in
all the buffers has been glitch free, so I have high hopes.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#8355: 24.0.50; Boxes in mode-line and scrolling

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> The scary thing about this fix is that the problematic code was in a
>> very low-level function, which is used all over the place, and that
>> code didn't change since Emacs 21.  So I wonder/dread what other
>> effects will this change have...
>
> It's exciting.  :-)  I've used the new version for some hours now, and
> in buffers with/without odd font combinations/images, and navigation in
> all the buffers has been glitch free, so I have high hopes.

It's been a month, and I've seen no glitches (or seen reports of them),
so I'm going to go ahead and close this bug report.  If there's further
work to be done in this area, opening a new bug report is probably the
way.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no