bug#34038: 26.1; set-window-start sometimes fails to set window start

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

To reproduce this issue, please start Emacs with "$ emacs -Q" and paste
at the end of the *scratch* buffer the following form:

    (progn
      (goto-char (point-max))
      (insert "\n")
      (dotimes (x (window-height))
        (insert (format "%s\n" x)))
      (redisplay)
      (let ((b (buffer-string))
            (p (point)))
        (set-window-start nil p t)
        (read-key "Please press a key to continue.")
        (erase-buffer)
        (insert b)
        (set-window-start nil p t)))

Then, put point at the end of the form, and evaluate it with C-x C-e.

Conceptually, this program:

     1) inserts several (i.e, window-height) lines into the buffer
     2) sets window point to p, which is point after (1)
     3) WAITS FOR A KEY PRESS (please press a key at this point)
     4) erases and restores the buffer contents
     5) sets window point to p, the same point as in (2)

However, in many invocations (please try it repeatedly if necessary),
the visible portion of the buffer unexpectedly differs between (3) and
after the whole procedure.

In other words, when Emacs waits for a key press, a different portion of
the buffer is visible compared to after you press a key, even though
window-start is set to the same position in both cases.

Is there a way to reliably set the window-start in such situations?

Thank you very much!
Markus

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2018-11-18 built on debian
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description:	Debian GNU/Linux 9.6 (stretch)

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Date: Thu, 10 Jan 2019 20:57:28 +0100
> 
>      1) inserts several (i.e, window-height) lines into the buffer
>      2) sets window point to p, which is point after (1)
>      3) WAITS FOR A KEY PRESS (please press a key at this point)
>      4) erases and restores the buffer contents
>      5) sets window point to p, the same point as in (2)
> 
> However, in many invocations (please try it repeatedly if necessary),
> the visible portion of the buffer unexpectedly differs between (3) and
> after the whole procedure.
> 
> In other words, when Emacs waits for a key press, a different portion of
> the buffer is visible compared to after you press a key, even though
> window-start is set to the same position in both cases.
> 
> Is there a way to reliably set the window-start in such situations?

I think this happens because you call set-window-start with last
argument non-nil.  Doing that tells the display engine that the
window-start point is just a suggestion, not a hard requirement.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> I think this happens because you call set-window-start with last
> argument non-nil.  Doing that tells the display engine that the
> window-start point is just a suggestion, not a hard requirement.

In the documentation of set-window-start, the last argument is described
as:

    Optional third arg NOFORCE non-nil inhibits next redisplay from
    overriding motion of point in order to display at this exact start.

From this text, this seems to be precisely what I need: I want to retain
point at this exact place, and I only want to change the window start,
not the point. In my use case, if I set this argument to "nil", then I
get unexpected point motion. Is there a way to reliably set window point
while at the same time preventing motion of point? I tried adding
(redisplay) at strategic places in my code, and this seems to work
somewhat better then, though at the cost of causing display flickering.

Thank you and all the best!
Markus

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 34038@debbugs.gnu.org
> Date: Fri, 11 Jan 2019 13:20:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think this happens because you call set-window-start with last
> > argument non-nil.  Doing that tells the display engine that the
> > window-start point is just a suggestion, not a hard requirement.
> 
> In the documentation of set-window-start, the last argument is described
> as:
> 
>     Optional third arg NOFORCE non-nil inhibits next redisplay from
>     overriding motion of point in order to display at this exact start.
> 
> >From this text, this seems to be precisely what I need: I want to retain
> point at this exact place, and I only want to change the window start,
> not the point. In my use case, if I set this argument to "nil", then I
> get unexpected point motion.

If displaying the window at the start point you request means point
will be outside of the window (or in the window margins, if you set
them), then redisplay has no alternative but move point to bring it
back into view.  If you prevent that, redisplay will not move point,
but it will also not necessarily obey the window-start value.

IOW, if there's a contradiction between the requested window-start and
showing point, the latter always wins in Emacs.

> Is there a way to reliably set window point while at the same time
> preventing motion of point?

How can you expect Emacs to do something like that?  It cannot
possibly do something that will leave point not displayed, can it?

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> IOW, if there's a contradiction between the requested window-start and
> showing point, the latter always wins in Emacs.

OK! However, in the snippet I posted, there appears to be no such
contradiction, because the window-start can be set to the intended
position while point is also displayed. This is illustrated before you
press a key when you run the snippet, and after you press a key, I would
like to reliably restore the exact same display situation as before.

>
> How can you expect Emacs to do something like that?  It cannot
> possibly do something that will leave point not displayed, can it?

I agree. However, that is not what I was requesting. What I need for my
use case is to reliably restore a configuration that I know is possible
to display on the grounds that it has already been displayed before. Is
there any way to do this, or could this please be provided?

Thank you and all the best,
Markus

bug#34038: 26.1; set-window-start sometimes fails to set window start

[martin rudalics]

 > I agree. However, that is not what I was requesting. What I need for my
 > use case is to reliably restore a configuration that I know is possible
 > to display on the grounds that it has already been displayed before. Is
 > there any way to do this, or could this please be provided?

 From you snippet I guess the following should do that.

     (progn
       (goto-char (point-max))
       (insert "\n")
       (dotimes (x (window-height))
         (insert (format "%s\n" x)))
       (redisplay)
       (let ((scroll-margin 1)
	    (b (buffer-string))
	    (s (window-start))
	    (p (point)))
         (read-key "Please press a key to continue.")
         (erase-buffer)
         (insert b)
         (set-window-point nil p)
         (set-window-start nil s)))

The crucial idiom is provided by the last two forms.  Restore window's
point first and then its start position (although any order should do
in your case).

martin

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Drew Adams]

> > Is there a way to reliably set the window-start in such situations?
> 
> I think this happens because you call set-window-start with last
> argument non-nil.  Doing that tells the display engine that the
> window-start point is just a suggestion, not a hard requirement.

Sorry for jumping in here ignorantly.  I just looked
at the doc string for `set-window-start' and got a
very different impression of what that 3rd arg means.
Am I mistaken?  How to reconcile your description
with what the doc string says?

  Optional third arg NOFORCE non-nil inhibits next
  redisplay from overriding motion of point in order
  to display at this exact start.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> Date: Fri, 11 Jan 2019 08:37:53 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 34038@debbugs.gnu.org
> 
> > I think this happens because you call set-window-start with last
> > argument non-nil.  Doing that tells the display engine that the
> > window-start point is just a suggestion, not a hard requirement.
> 
> Sorry for jumping in here ignorantly.  I just looked
> at the doc string for `set-window-start' and got a
> very different impression of what that 3rd arg means.
> Am I mistaken?  How to reconcile your description
> with what the doc string says?
> 
>   Optional third arg NOFORCE non-nil inhibits next
>   redisplay from overriding motion of point in order
>   to display at this exact start.

I don't think I see the difficulty, the doc string seems to tell
exactly what I did, albeit in a different way.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> The crucial idiom is provided by the last two forms.  Restore window's
> point first and then its start position (although any order should do
> in your case).

This indeed works for the particular snippet I posted. However, I have a
more complex application where I am already using set-window-point, and
this does not fix the issue.

However, in the application for which I need this functionality, it
works completely as intended if I add (redisplay) between the calls of
set-window-point and set-window-start.

From this, I get the impression that a pending redisplay may interfere
with reliably setting the window-start even if window-point is set!

All the best,
Markus

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: Eli Zaretskii <eliz@gnu.org>,  34038@debbugs.gnu.org
> Date: Fri, 11 Jan 2019 18:45:53 +0100
> 
> >From this, I get the impression that a pending redisplay may interfere
> with reliably setting the window-start even if window-point is set!

If you call set-window-start with last argument non-nil, redisplay is
under no obligation to honor your window-start.  It tries to use it,
but if it doesn't fit, for whatever reason, it disregards it.

So as along as you call set-window-start this way, you cannot rely on
the window-start point you set to be honored.  It might be, except
when it won't be.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Alan Mackenzie]

Hello, Markus.

Your original form:

    (progn
      (goto-char (point-max))
      (insert "\n")
      (dotimes (x (window-height))
        (insert (format "%s\n" x)))
      (redisplay)
      (let ((b (buffer-string))
            (p (point)))
        (set-window-start nil p t)
        (read-key "Please press a key to continue.")
        (erase-buffer)
        (insert b)
        (set-window-start nil p t)))

On Fri, Jan 11, 2019 at 13:20:33 +0100, Markus Triska wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> > I think this happens because you call set-window-start with last
> > argument non-nil.  Doing that tells the display engine that the
> > window-start point is just a suggestion, not a hard requirement.

> In the documentation of set-window-start, the last argument is described
> as:

>     Optional third arg NOFORCE non-nil inhibits next redisplay from
>     overriding motion of point in order to display at this exact start.

> >From this text, this seems to be precisely what I need: I want to retain
> point at this exact place, and I only want to change the window start,
> not the point. In my use case, if I set this argument to "nil", then I
> get unexpected point motion. Is there a way to reliably set window point
> while at the same time preventing motion of point? I tried adding
> (redisplay) at strategic places in my code, and this seems to work
> somewhat better then, though at the cost of causing display flickering.

> Thank you and all the best!
> Markus

I've played with this for several hours, and my feeling, like yours, is
that there's a bug in there, somewhere.

If you set scroll-conservatively to a non-zero value, your form behaves
properly.  This suggests that the problem is in redisplay rather than
set-window-start itself.

If you remove the erase-buffer and insert forms from the form,
(replacing them with an (end-of-buffer)), again you get the desired
behaviour.

M-: (set-window-start nil (point-max) t) appears to behave correctly.

A bit of debugging output shows that after (erase-buffer), window-start
is already at 1, not the former point-max.  After (insert b),
window-start continues to be at 1.

erase-buffer and insert are doing something strange with internal
display variables.  I tried seeing if this was the w->force_start field
of the window structure (that's the field which gets set to true when
one calls set-window-start _without_ a non-nil NOFORCE, but doesn't get
cleared when NOFORCE is non-nil; I think only redisplay clears it).  But
this isn't it.

There might be a clue in the entry for set-window-start in the manual,
which says:

     If NOFORCE is non-`nil', and POSITION would place point off screen
     at the next redisplay, then redisplay computes a new window-start
     position that works well with point, and thus POSITION is not used.
 
.  This is pure speculation, but perhaps because the entire buffer is
currently off the screen, with point being on the empty last line,
redisplay is somehow thinking that point is off screen too.  If this is
the case, it would explain why redisplay scrolls the buffer to put point
on the middle window line.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#34038: 26.1; set-window-start sometimes fails to set window start

[martin rudalics]

 > This indeed works for the particular snippet I posted. However, I have a
 > more complex application where I am already using set-window-point, and
 > this does not fix the issue.

All we need to know for why this happens would be the exact sequence
of (window) point and window start settting operations performed by
that application.

 > However, in the application for which I need this functionality, it
 > works completely as intended if I add (redisplay) between the calls of
 > set-window-point and set-window-start.
 >
 >>From this, I get the impression that a pending redisplay may interfere
 > with reliably setting the window-start even if window-point is set!

One more reason to dig further into this.

martin

bug#34038: 26.1; set-window-start sometimes fails to set window start

[martin rudalics]

 > A bit of debugging output shows that after (erase-buffer), window-start
 > is already at 1, not the former point-max.

'window-start' returns the position of the window start marker.  When
you erase a buffer _all_ its markers go to point-min - point-max and
all window start or point markers included.

 > After (insert b),
 > window-start continues to be at 1.

Because the insertion type of a window start marker is nil.  You can
use 'insert-before-markers' to override that.

martin

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> All we need to know for why this happens would be the exact sequence
> of (window) point and window start settting operations performed by
> that application.

The actual application performs actions that are quite involved, so I
try to break it down to simpler cases that need fewer operations.

For example, please try the following snippet:

    (progn
      (goto-char (point-max))
      (insert "\n")
      (dotimes (x (window-height))
        (insert (format "%s\n" x)))
      (let ((b (buffer-string))
            (p (point)))
        (redisplay)
        (set-window-start nil p)
        (let ((wp (window-point)))
          (read-key "Step 1. Please press a key to continue.")
          (dotimes (x (round (/ (window-height) 2)))
            (insert (format "more lines ... %s\n" x)))
          (read-key "Step 2. Please press a key to continue.")    
          (erase-buffer)
          (insert b)
          (set-window-point nil wp)
          (set-window-start nil p))))

In this snippet, I try to restore the exact same configuration that you
see when "Step 1 ..." is displayed, i.e., window-start is set so that
point is on the very first line, which is blank. When you press a key at
this point, then a few more lines of text are inserted. Then, please
press another key when "Step 2 ..." is displayed.

What I observe after these forms is that point is unexpectedly placed
vertically centered in the window instead of at the topmost line.

Please note that I am now using set-window-point, and also
set-window-start with third argument (implicitly) nil. I get the exact
same result when I use t for the third argument of set-window-start.

Can you reproduce this? Is there a way to reliably restore this?

Thank you and all the best!
Markus

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: Eli Zaretskii <eliz@gnu.org>,  34038@debbugs.gnu.org
> Date: Sat, 12 Jan 2019 14:25:57 +0100
> 
> In this snippet, I try to restore the exact same configuration that you
> see when "Step 1 ..." is displayed, i.e., window-start is set so that
> point is on the very first line, which is blank. When you press a key at
> this point, then a few more lines of text are inserted. Then, please
> press another key when "Step 2 ..." is displayed.
> 
> What I observe after these forms is that point is unexpectedly placed
> vertically centered in the window instead of at the topmost line.

Maybe I didn't invoke the recipe exactly as you do, but here I get the
result you expect, I think: point is on the topmost line.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[martin rudalics]

 >      (progn
 >        (goto-char (point-max))
 >        (insert "\n")
 >        (dotimes (x (window-height))
 >          (insert (format "%s\n" x)))
 >        (let ((b (buffer-string))
 >              (p (point)))
 >          (redisplay)
 >          (set-window-start nil p)
 >          (let ((wp (window-point)))
 >            (read-key "Step 1. Please press a key to continue.")
 >            (dotimes (x (round (/ (window-height) 2)))
 >              (insert (format "more lines ... %s\n" x)))
 >            (read-key "Step 2. Please press a key to continue.")
 >            (erase-buffer)
 >            (insert b)
 >            (set-window-point nil wp)
 >            (set-window-start nil p))))
 >
 > In this snippet, I try to restore the exact same configuration that you
 > see when "Step 1 ..." is displayed, i.e., window-start is set so that
 > point is on the very first line, which is blank. When you press a key at

I think you mean on the very _last_ line here.  Right?

 > this point, then a few more lines of text are inserted. Then, please
 > press another key when "Step 2 ..." is displayed.
 >
 > What I observe after these forms is that point is unexpectedly placed
 > vertically centered in the window instead of at the topmost line.
 >
 > Please note that I am now using set-window-point, and also
 > set-window-start with third argument (implicitly) nil. I get the exact
 > same result when I use t for the third argument of set-window-start.
 >
 > Can you reproduce this? Is there a way to reliably restore this?

I see a centering but I'm not sure whether I see the same thing
happening as you do.  Evaluating

(progn
   (goto-char (point-max))
   (insert "\n")
   (dotimes (x (window-height))
     (insert (format "%s\n" x)))
   (let ((b (buffer-string))
         (p (point)))
     (redisplay)
     (set-window-start nil p)
     (let ((wp (window-point)))
       (read-key (format "Step 1 at %s wp is %s. Please press a key to continue." (point) wp))
       (dotimes (x (round (/ (window-height) 2)))
         (insert (format "more lines ... %s\n" x)))
       (read-key (format "Step 2 at %s wp is %s. Please press a key to continue." (point) wp))
       (erase-buffer)
       (insert b)
       (set-window-point nil wp)
       (set-window-start nil p))))

in an empty *scratch* buffer here gives 97..97 and 393..97 for (point)
and wp.  Do you see that?

If so then does (setq scroll-conservatively 101) fix it?

martin

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Alan Mackenzie]

Hello, Martin.

On Sat, Jan 12, 2019 at 09:13:07 +0100, martin rudalics wrote:
>  > A bit of debugging output shows that after (erase-buffer), window-start
>  > is already at 1, not the former point-max.

> 'window-start' returns the position of the window start marker.  When
> you erase a buffer _all_ its markers go to point-min - point-max and
> all window start or point markers included.

Of course!  I don't know what I was thinking at the time.  Markers
behave like markers, and w->start in struct window is just an ordinary
marker.  Sorry for writing rubbish.

>  > After (insert b),
>  > window-start continues to be at 1.

> Because the insertion type of a window start marker is nil.  You can
> use 'insert-before-markers' to override that.

Yes.  The question remains, what is causing the unexpected scrolling in
the OP's scenario?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

>> In this snippet, I try to restore the exact same configuration that you
>> see when "Step 1 ..." is displayed, i.e., window-start is set so that
>> point is on the very first line, which is blank. When you press a key at
>
> I think you mean on the very _last_ line here.  Right?

I mean point is at the first line that is shown in the window, i.e.,
point is at the topmost left position in the window, and yes, that is
the last line of the buffer.

> in an empty *scratch* buffer here gives 97..97 and 393..97 for (point)
> and wp.  Do you see that?

I get:

    Step 1 at 79 wp is 79
    Step 2 at 321 wp is 79

where (frame-height) yields 30, and (window-height) yields 29.

> If so then does (setq scroll-conservatively 101) fix it?

Yes, with scroll-conservatively set to 101, I get the intended effect,
i.e., the same position of window point as after Step 1 (79) also after
the whole form is evaluated! This is what I expect also with the default
settings, i.e., scroll-conservatively set to 0, for this snippet.

Thank you and all the best,
Markus

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: Eli Zaretskii <eliz@gnu.org>,  34038@debbugs.gnu.org
> Date: Sat, 12 Jan 2019 20:08:23 +0100
> 
> > If so then does (setq scroll-conservatively 101) fix it?
> 
> Yes, with scroll-conservatively set to 101, I get the intended effect,
> i.e., the same position of window point as after Step 1 (79) also after
> the whole form is evaluated! This is what I expect also with the default
> settings, i.e., scroll-conservatively set to 0, for this snippet.

Most probably, given the size of your default font, the last line of
the window is not fully visible, and so Emacs recenters point to make
its line visible.  With scroll-conservatively it intentionally avoids
doing that because that's what scroll-conservatively is all about.
But that option sometimes causes expensive calculations during
redisplay, and many people don't like the effect even when it causes
no slow-down, so it is not the default.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> Date: Sat, 12 Jan 2019 18:22:03 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Markus Triska <triska@metalevel.at>, 34038@debbugs.gnu.org
> 
> The question remains, what is causing the unexpected scrolling in
> the OP's scenario?

Almost certainly the fact that the last window's line is not 100%
visible.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Alan Mackenzie]

Hello, Eli.

On Sat, Jan 12, 2019 at 22:29:25 +0200, Eli Zaretskii wrote:
> > Date: Sat, 12 Jan 2019 18:22:03 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Markus Triska <triska@metalevel.at>, 34038@debbugs.gnu.org

> > The question remains, what is causing the unexpected scrolling in
> > the OP's scenario?

> Almost certainly the fact that the last window's line is not 100%
> visible.

No, it's not that, or at least, not only that.  I see the scrolling on
my Linux tty, where lines cannot be partially visible.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> Date: Sat, 12 Jan 2019 20:42:04 +0000
> Cc: rudalics@gmx.at, triska@metalevel.at, 34038@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Almost certainly the fact that the last window's line is not 100%
> > visible.
> 
> No, it's not that, or at least, not only that.  I see the scrolling on
> my Linux tty, where lines cannot be partially visible.

What do you mean by "you see the scrolling"?  The recipe as published
shows the results only once, at the end, so there's nothing to compare
that display with to say there was scrolling.

What am I missing here?

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

Hi Alan,

thank you for looking into this, I greatly appreciate it!

Alan Mackenzie <acm@muc.de> writes:

> .  This is pure speculation, but perhaps because the entire buffer is
> currently off the screen, with point being on the empty last line,

This indeed seems to be a critical factor: an empty last line that
appears as the first line of the window.

The reason I think that is because if you add for example just a single
space to the line, everything works exactly as expected:

    (progn
      (goto-char (point-max))
      (insert "\n")
      (dotimes (x (window-height))
        (insert (format "%s\n" x)))
      (insert " ")
      (backward-char 1)
      (let ((b (buffer-string))
            (p (point)))
        (redisplay)
        (set-window-start nil p)
        (let ((wp (window-point)))
          (read-key (format "Step 1 at %s wp is %s. Please press a key to continue." (point) wp))
          (dotimes (x (round (/ (window-height) 2)))
            (insert (format "more lines ... %s\n" x)))
          (read-key (format "Step 2 at %s wp is %s. Please press a key to continue." (point) wp))
          (erase-buffer)
          (insert b)
          (set-window-point nil wp)
          (set-window-start nil p))))

Please note the (insert " "). I am using (backward-char 1) to show that
the position of point by itself is not enough to trigger the phenomenon.

Thank you and all the best!
Markus

bug#34038: 26.1; set-window-start sometimes fails to set window start

[martin rudalics]

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

 > This indeed seems to be a critical factor: an empty last line that
 > appears as the first line of the window.

I think I now distilled a fairly simply recipe to watch the problem.
Load the attached file with emacs -Q and type C-.

Note that *scratch* contains no empty line when finally displayed.
Also, here C-. displays the desired result with window-start at
point-max for a short moment before making the buffer fully visible.
Setting 'scroll-conservatively' to 101 fixes the problem.

martin

[-- Attachment #2: foobar.el --]
[-- Type: application/emacs-lisp, Size: 289 bytes --]

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

On January 13, 2019 10:40:20 AM GMT+02:00, martin rudalics <rudalics@gmx.at> wrote:
>  > This indeed seems to be a critical factor: an empty last line that
>  > appears as the first line of the window.
> 
> I think I now distilled a fairly simply recipe to watch the problem.
> Load the attached file with emacs -Q and type C-.
> 
> Note that *scratch* contains no empty line when finally displayed.
> Also, here C-. displays the desired result with window-start at
> point-max for a short moment before making the buffer fully visible.
> Setting 'scroll-conservatively' to 101 fixes the problem.
> 
> martin

There's no bug here: Emacs by default avoids starting a window's display at EOB.  Scroll-conservatively overrides that.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[martin rudalics]

 > There's no bug here: Emacs by default avoids starting a window's
 > display at EOB.  Scroll-conservatively overrides that.

AFAICT a first redisplay tries to obey a forced 'window-start' at EOB.
A subsequent redisplay_preserve_echo_area, however, has forgotten the
force_start and recenters the window.  Which means that force_start is
pretty ephemeral.

martin

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> Date: Sun, 13 Jan 2019 14:40:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34038@debbugs.gnu.org
> 
>  > There's no bug here: Emacs by default avoids starting a window's
>  > display at EOB.  Scroll-conservatively overrides that.
> 
> AFAICT a first redisplay tries to obey a forced 'window-start' at EOB.
> A subsequent redisplay_preserve_echo_area, however, has forgotten the
> force_start and recenters the window.

Yes.

> Which means that force_start is pretty ephemeral.

It's ephemeral if it leaves the window in a state which will make
subsequent redisplay unhappy.  Which is what this recipe triggers.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

>> Which means that force_start is pretty ephemeral.
>
> It's ephemeral if it leaves the window in a state which will make
> subsequent redisplay unhappy.  Which is what this recipe triggers.

I have found another case of this issue (i.e., set-window-start fails to
set window-start). In emacs -Q, please evaluate the following form in
the *scratch* buffer:

    (progn
      (delete-region (point) (point-max))
      (insert "\n")
      (set-window-start nil 1)
      (goto-char (point-max))
      (while t
        (insert "test\n")
        (unless (pos-visible-in-window-p (point))
          (redisplay)
          (let ((start (window-start)))
            (if (= start 1)
                (error "window-start is now 1 (as expected), please try a different text-scale-amount")
              (error "window-start is now unexpectedly %s (instead of 1)" start))))))

This sets, and sometimes fails to set, window-start to 1, apparently
depending on the amount of text-scale:

When I evaluate this with text-scale-mode-amount set to 0, window-start
is correctly set to 1. However, when I change the amount of text-scale
with either C-x C-= or C-x C--, then, after the form stops evaluating,
window-start is at other positions. In that case, even when I then
manually try to set the window-start to 1 with:

    M-: (set-window-start nil 1) RET

then the window-start is not set to 1, but remains at the same position.
Is this due to the same issue, or should I rather file this separately?

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: martin rudalics <rudalics@gmx.at>,  acm@muc.de,  34038@debbugs.gnu.org
> Date: Sun, 24 Mar 2019 11:35:07 +0100
> 
> I have found another case of this issue (i.e., set-window-start fails to
> set window-start). In emacs -Q, please evaluate the following form in
> the *scratch* buffer:
> 
>     (progn
>       (delete-region (point) (point-max))
>       (insert "\n")
>       (set-window-start nil 1)
>       (goto-char (point-max))
>       (while t
>         (insert "test\n")
>         (unless (pos-visible-in-window-p (point))
>           (redisplay)
>           (let ((start (window-start)))
>             (if (= start 1)
>                 (error "window-start is now 1 (as expected), please try a different text-scale-amount")
>               (error "window-start is now unexpectedly %s (instead of 1)" start))))))
> 
> This sets, and sometimes fails to set, window-start to 1, apparently
> depending on the amount of text-scale:
> 
> When I evaluate this with text-scale-mode-amount set to 0, window-start
> is correctly set to 1. However, when I change the amount of text-scale
> with either C-x C-= or C-x C--, then, after the form stops evaluating,
> window-start is at other positions. In that case, even when I then
> manually try to set the window-start to 1 with:
> 
>     M-: (set-window-start nil 1) RET
> 
> then the window-start is not set to 1, but remains at the same position.
> Is this due to the same issue, or should I rather file this separately?

Most probably it is the same issue.  However, I'm not really sure what
surprised you in this behavior, so how about describing what you
thought should have happened here, step by step, in contrast with what
did happen?  I believe I then will be able to provide a more accurate
answer to your question.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> describing what you thought should have happened here, step by step,

My expectation is that, when the snippet terminates with the message
that window-start is unexpectedly at a position different from 1, and I
*then* do:

    M-: (set-window-start nil 1) RET

that the window-start is set to 1. However, in such cases, at least on
my machine and in the cases I found, the window start is *not* set to 1,
but unexpectedly retained at a position different from 1.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: rudalics@gmx.at,  acm@muc.de,  34038@debbugs.gnu.org
> Date: Sun, 24 Mar 2019 20:56:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > describing what you thought should have happened here, step by step,
> 
> My expectation is that, when the snippet terminates with the message
> that window-start is unexpectedly at a position different from 1, and I
> *then* do:
> 
>     M-: (set-window-start nil 1) RET
> 
> that the window-start is set to 1. However, in such cases, at least on
> my machine and in the cases I found, the window start is *not* set to 1,
> but unexpectedly retained at a position different from 1.

This is actually quite expected: you cannot rely on set-window-start
to always produce what you want, if the start position doesn't
guarantee that point will be on a fully visible line.  If with the
start point you set point is not fully visible, redisplay is free not
to obey that start point.  It does make an attempt to use the start
point you provide and move point into the view-port, but the attempt
is half-hearted, and is likely to fail when the size of the default
face's font is different from the frame's default font, because the
last screen line of the window is then typically only partially
visible.

Can you describe what you are trying to achieve by using
set-window-start?  It's somewhat unusual to use that API without also
moving point accordingly.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you describe what you are trying to achieve by using
> set-window-start?  It's somewhat unusual to use that API without also
> moving point accordingly.

I noticed these issues in a larger application, primarily in an attempt
to reliably and fully restore a previous window configuration.

The key issue seems to be that point must be set correctly: If point is
at a position that is known to be displayable with a given window-start,
then if point is again set to that position, set-window-start will also
reliably set window-start to that start. Is this correct?

Personally, I would appreciate some comment regarding such a guarantee,
or the assumptions, in the documentation of set-window-start.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: rudalics@gmx.at,  acm@muc.de,  34038@debbugs.gnu.org
> Date: Fri, 29 Mar 2019 08:16:25 +0100
> 
> The key issue seems to be that point must be set correctly: If point is
> at a position that is known to be displayable with a given window-start,
> then if point is again set to that position, set-window-start will also
> reliably set window-start to that start. Is this correct?

Yes.  In fact, that's how set-window-start was intended to work to
begin with: for applications that put point at certain location, and
also want to control where the window display will start on next
redisplay.  Scrolling commands behave that way, for example.

> Personally, I would appreciate some comment regarding such a guarantee,
> or the assumptions, in the documentation of set-window-start.

OK, I will add something to that effect, thanks for pointing this out.

bug#34038: 26.1; set-window-start sometimes fails to set window start

[Eli Zaretskii]

> Date: Fri, 29 Mar 2019 11:29:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 34038@debbugs.gnu.org, acm@muc.de
> 
> > Personally, I would appreciate some comment regarding such a guarantee,
> > or the assumptions, in the documentation of set-window-start.
> 
> OK, I will add something to that effect, thanks for pointing this out.

Now done on the emacs-26 branch.