[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#34038: 26.1; set-window-start sometimes fails to set window start
Date: Thu, 28 Mar 2019 18:21:53 +0200

> From: Markus Triska <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Sun, 24 Mar 2019 20:56:34 +0100
> Eli Zaretskii <address@hidden> 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

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.

reply via email to

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