Question about weird vscroll behavior

Question about weird vscroll behavior

[dalanicolai]

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

Hi,

I am experiencing some weird behavior. I am simply trying to set the
vscroll. For that I first created a single overlay displaying a large
space and then use set-window-vscroll to set the vscroll.

It works when I simply load my Emacs configuration, but for some
reason it does not work when I start from emacs -Q.

Although I guess vscroll should be working on lines smaller than the
screen, just for testing I now display 3 'spaces' and then try to set
vscroll as follows:

(progn
>   (pop-to-buffer "example")
>   (dotimes (i 3)
>     (let ((o (make-overlay (point)
>                            (progn (insert " ")
>                                   (point)))))
>       (insert "\n")
>       (overlay-put o 'display `(space . (:width (600) :height (800))))
>       (overlay-put o 'face (list :background (pcase (% i 3)
>                                                (0 "red")
>                                                (1 "green")
>                                                (2 "blue"))))))
>   (goto-char (point-min))
>
>   (set-window-vscroll nil 300 t))
>

I have tested it on Emacs 29.1 and 28.3.

I wonder if this is a bug, or if I am missing something.  Could you
please evaluate the above code starting from emacs -Q, and confirm
this is a bug (or tell me what I am missing)?

Thanks

[-- Attachment #2: Type: text/html, Size: 1750 bytes --]

Re: Question about weird vscroll behavior

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sun, 5 Nov 2023 16:49:04 +0100
> 
> It works when I simply load my Emacs configuration, but for some
> reason it does not work when I start from emacs -Q.
> 
> Although I guess vscroll should be working on lines smaller than the
> screen, just for testing I now display 3 'spaces' and then try to set
> vscroll as follows:
> 
>  (progn
>    (pop-to-buffer "example")
>    (dotimes (i 3)
>      (let ((o (make-overlay (point)
>                             (progn (insert " ")
>                                    (point)))))
>        (insert "\n")
>        (overlay-put o 'display `(space . (:width (600) :height (800))))
>        (overlay-put o 'face (list :background (pcase (% i 3)
>                                                 (0 "red")
>                                                 (1 "green")
>                                                 (2 "blue"))))))
>    (goto-char (point-min))
>      
>    (set-window-vscroll nil 300 t))
> 
> I have tested it on Emacs 29.1 and 28.3.
> 
> I wonder if this is a bug, or if I am missing something.  Could you
> please evaluate the above code starting from emacs -Q, and confirm
> this is a bug (or tell me what I am missing)?

Works for me in "emacs -Q".

Re: Question about weird vscroll behavior

[dalanicolai]

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

Thank you Eli,

I just realized I forgot to be clear about my question.
The problem is that after evaluating the code, here,
after starting from emacs -Q, the vscroll value is still
zero.

So I was wondering what is the value when doing

> M-: (window-vscroll nil t)
>
after evaluating the example code.

So Eli, when you say it works, do you mean that
vscroll value is 300?

Thanks again...

On Sun, 5 Nov 2023 at 17:20, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > Date: Sun, 5 Nov 2023 16:49:04 +0100
> >
> > It works when I simply load my Emacs configuration, but for some
> > reason it does not work when I start from emacs -Q.
> >
> > Although I guess vscroll should be working on lines smaller than the
> > screen, just for testing I now display 3 'spaces' and then try to set
> > vscroll as follows:
> >
> >  (progn
> >    (pop-to-buffer "example")
> >    (dotimes (i 3)
> >      (let ((o (make-overlay (point)
> >                             (progn (insert " ")
> >                                    (point)))))
> >        (insert "\n")
> >        (overlay-put o 'display `(space . (:width (600) :height (800))))
> >        (overlay-put o 'face (list :background (pcase (% i 3)
> >                                                 (0 "red")
> >                                                 (1 "green")
> >                                                 (2 "blue"))))))
> >    (goto-char (point-min))
> >
> >    (set-window-vscroll nil 300 t))
> >
> > I have tested it on Emacs 29.1 and 28.3.
> >
> > I wonder if this is a bug, or if I am missing something.  Could you
> > please evaluate the above code starting from emacs -Q, and confirm
> > this is a bug (or tell me what I am missing)?
>
> Works for me in "emacs -Q".
>

[-- Attachment #2: Type: text/html, Size: 2900 bytes --]

Re: Question about weird vscroll behavior

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Sun, 5 Nov 2023 17:36:26 +0100
> Cc: emacs-devel@gnu.org
> 
> I just realized I forgot to be clear about my question.
> The problem is that after evaluating the code, here,
> after starting from emacs -Q, the vscroll value is still
> zero.
> 
> So I was wondering what is the value when doing
> 
>  M-: (window-vscroll nil t)
> 
> after evaluating the example code.
> 
> So Eli, when you say it works, do you mean that
> vscroll value is 300?

Of course!  How else could I have claimed that "it works"?

Re: Question about weird vscroll behavior

[dalanicolai]

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

Haha, okay Eli. It was just to be sure, because otherwise I have
no idea why setting the vscroll using the above code, does not
work here.

I have tried with the Fedora system Emacs 28.3, and with my own
build of Emacs 29.1 (with PGTK, but I guess that is the default now
on Emacs 29). Also, I have tried on wayland and x-org. But the code
does not set the vscroll when starting from emacs -Q, while, strangely
it works when I load my configuration.

Anyway, I guess I have to investigate some more then.

Thanks a lot for checking!


On Sun, 5 Nov 2023 at 18:01, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > Date: Sun, 5 Nov 2023 17:36:26 +0100
> > Cc: emacs-devel@gnu.org
> >
> > I just realized I forgot to be clear about my question.
> > The problem is that after evaluating the code, here,
> > after starting from emacs -Q, the vscroll value is still
> > zero.
> >
> > So I was wondering what is the value when doing
> >
> >  M-: (window-vscroll nil t)
> >
> > after evaluating the example code.
> >
> > So Eli, when you say it works, do you mean that
> > vscroll value is 300?
>
> Of course!  How else could I have claimed that "it works"?
>

[-- Attachment #2: Type: text/html, Size: 1873 bytes --]

Re: Question about weird vscroll behavior

[dalanicolai]

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

Hi all,

If there is anybody on Fedora here, could you please try to evaluate the
code
from the original message starting from emacs -Q, and afterwards check what
is the value of

M-: (window-vscroll nil t)
>

Do you get 0 or 300?

For some reason this does not work here. I have just built emacs from `HEAD`
without using any `configure` flags. It does not work here, neither on
emacs 28.3, 29.1 or on the latest 30.5.

I have also tried on Ubuntu on another laptop, where the code works fine.
Would be great if possible.

Thanks!

On Sun, 5 Nov 2023 at 19:14, dalanicolai <dalanicolai@gmail.com> wrote:

> Haha, okay Eli. It was just to be sure, because otherwise I have
> no idea why setting the vscroll using the above code, does not
> work here.
>
> I have tried with the Fedora system Emacs 28.3, and with my own
> build of Emacs 29.1 (with PGTK, but I guess that is the default now
> on Emacs 29). Also, I have tried on wayland and x-org. But the code
> does not set the vscroll when starting from emacs -Q, while, strangely
> it works when I load my configuration.
>
> Anyway, I guess I have to investigate some more then.
>
> Thanks a lot for checking!
>
>
> On Sun, 5 Nov 2023 at 18:01, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: dalanicolai <dalanicolai@gmail.com>
>> > Date: Sun, 5 Nov 2023 17:36:26 +0100
>> > Cc: emacs-devel@gnu.org
>> >
>> > I just realized I forgot to be clear about my question.
>> > The problem is that after evaluating the code, here,
>> > after starting from emacs -Q, the vscroll value is still
>> > zero.
>> >
>> > So I was wondering what is the value when doing
>> >
>> >  M-: (window-vscroll nil t)
>> >
>> > after evaluating the example code.
>> >
>> > So Eli, when you say it works, do you mean that
>> > vscroll value is 300?
>>
>> Of course!  How else could I have claimed that "it works"?
>>
>

[-- Attachment #2: Type: text/html, Size: 3149 bytes --]

Re: Question about weird vscroll behavior

[dalanicolai]

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

I have discovered that the behavior seems to occur on all systems, but
that I forgot to mention another single step, which is that I am
maximizing the Emacs window first, using the GNOME desktop shortcut
(Super + Arrow Up). However, the behavior is the same (i.e. vscroll
does not get set) when using 'M-x toggle-frame-maximized' before
trying the code snippet.

Now, the docstring of 'set-window-vscroll' says:

'PRESERVE-VSCROLL-P makes setting the start of WINDOW preserve the
vscroll if its start is "frozen" due to a resized mini-window.'

I don't really understand what that sentence means, so I am now still
wondering if this behavior could be considered a bug or not.

Should I report this as a bug?

Thanks





On Sun, 5 Nov 2023 at 21:17, dalanicolai <dalanicolai@gmail.com> wrote:

> Hi all,
>
> If there is anybody on Fedora here, could you please try to evaluate the
> code
> from the original message starting from emacs -Q, and afterwards check what
> is the value of
>
> M-: (window-vscroll nil t)
>>
>
> Do you get 0 or 300?
>
> For some reason this does not work here. I have just built emacs from
> `HEAD`
> without using any `configure` flags. It does not work here, neither on
> emacs 28.3, 29.1 or on the latest 30.5.
>
> I have also tried on Ubuntu on another laptop, where the code works fine.
> Would be great if possible.
>
> Thanks!
>
> On Sun, 5 Nov 2023 at 19:14, dalanicolai <dalanicolai@gmail.com> wrote:
>
>> Haha, okay Eli. It was just to be sure, because otherwise I have
>> no idea why setting the vscroll using the above code, does not
>> work here.
>>
>> I have tried with the Fedora system Emacs 28.3, and with my own
>> build of Emacs 29.1 (with PGTK, but I guess that is the default now
>> on Emacs 29). Also, I have tried on wayland and x-org. But the code
>> does not set the vscroll when starting from emacs -Q, while, strangely
>> it works when I load my configuration.
>>
>> Anyway, I guess I have to investigate some more then.
>>
>> Thanks a lot for checking!
>>
>>
>> On Sun, 5 Nov 2023 at 18:01, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> > From: dalanicolai <dalanicolai@gmail.com>
>>> > Date: Sun, 5 Nov 2023 17:36:26 +0100
>>> > Cc: emacs-devel@gnu.org
>>> >
>>> > I just realized I forgot to be clear about my question.
>>> > The problem is that after evaluating the code, here,
>>> > after starting from emacs -Q, the vscroll value is still
>>> > zero.
>>> >
>>> > So I was wondering what is the value when doing
>>> >
>>> >  M-: (window-vscroll nil t)
>>> >
>>> > after evaluating the example code.
>>> >
>>> > So Eli, when you say it works, do you mean that
>>> > vscroll value is 300?
>>>
>>> Of course!  How else could I have claimed that "it works"?
>>>
>>

[-- Attachment #2: Type: text/html, Size: 4393 bytes --]

Re: Question about weird vscroll behavior

[Eli Zaretskii]

> From: dalanicolai <dalanicolai@gmail.com>
> Date: Fri, 10 Nov 2023 19:51:44 +0100
> 
> Now, the docstring of 'set-window-vscroll' says:
> 
> 'PRESERVE-VSCROLL-P makes setting the start of WINDOW preserve the
> vscroll if its start is "frozen" due to a resized mini-window.'
> 
> I don't really understand what that sentence means

It talks about resizing the mini-window, the window at the bottom of
the frame where Emacs shows the echo-area and the minibuffer.  So this
is unrelated to maximizing the Emacs frame.


> so I am now still
> wondering if this behavior could be considered a bug or not.
> 
> Should I report this as a bug?

I don't know.  In general, window-vscroll gets reset in many
situations, so what you see is most probably not a bug.