GNU bug report logs - #79351
30.2; window-resize-symbollwise

Previous Next

To reply to this bug, email your comments to 79351 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; window-resize-symbollwise
Date: Sun, 31 Aug 2025 05:24:36 +0300

[Message part 1 (text/plain, inline)]

Hello!
It's a UX feature request.

There's a window-resize-pixelwise, but no window-resize-symbollwise:
what I want, as a user, is to have a similar user experience to the
-nw version of Emacs under graphical environment.

Currently even with the window-resize-pixelwise nil, and with the
pixel-scroll-precision-mode nil, there's a cases when during window
resizing, modeline appears in-the-middle of the character line or
jumping around inconsistently.  What I expect is a smooth UX where
each windows has a whole number of rows and columns.  An example of
such a wrong user case attached.

-- 
With best regards,
Yuriy Pitomets

[Screenshot from 2025-08-31 05-23-45.png (image/png, attachment)]

Message #8 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yurii Pytomets <pitometsu <at> gmail.com>,
 martin rudalics <rudalics <at> gmx.at>
Cc: 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Sun, 31 Aug 2025 08:26:40 +0300

> From: Yurii Pytomets <pitometsu <at> gmail.com>
> Date: Sun, 31 Aug 2025 05:24:36 +0300
> 
> It's a UX feature request.
> 
> There's a window-resize-pixelwise, but no window-resize-symbollwise:
> what I want, as a user, is to have a similar user experience to the
> -nw version of Emacs under graphical environment.
> 
> Currently even with the window-resize-pixelwise nil, and with the
> pixel-scroll-precision-mode nil, there's a cases when during window
> resizing, modeline appears in-the-middle of the character line or
> jumping around inconsistently.  What I expect is a smooth UX where
> each windows has a whole number of rows and columns.  An example of
> such a wrong user case attached.

According to the manual, window-resize-pixelwise = nil is what you
want.  However, it currently doesn't affect dragging the window border
with the mouse, AFAIU.  Martin, am I right?  This could be a simple
omission.

Message #11 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Sun, 31 Aug 2025 08:46:42 +0300

[Please always use Reply to All to reply, otherwise the response is
sent only to me personally.]

> From: Yurii Pytomets <pitometsu <at> gmail.com>
> Date: Sun, 31 Aug 2025 08:38:46 +0300
> 
> Pretty sure, the frame resizing could affect it too, by causing
> inconsistency in modeline/separators alignments.

Message #14 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Yurii Pytomets <pitometsu <at> gmail.com>
Cc: 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Sun, 31 Aug 2025 09:31:18 +0200

> According to the manual, window-resize-pixelwise = nil is what you
> want.  However, it currently doesn't affect dragging the window border
> with the mouse, AFAIU.  Martin, am I right?  This could be a simple
> omission.

You and Stefan wanted mouse dragging to work pixelwise.  See the
discussion in Bug#16594.

commit a1a04df94c2cdea0f24733aa9b1892ee7ba50b13
Author: Eli Zaretskii <eliz <at> gnu.org>
Date:   Thu Jan 30 19:42:48 2014 +0200

    Revert last commit in mouse.el.

commit df1834593692c4103f89de90aaa882a2fb404eb6
Author: Martin Rudalics <rudalics <at> gmx.at>
Date:   Thu Jan 30 14:19:19 2014 +0100

    In mouse-drag-line obey window-resize-pixelwise (Bug#16594).

    * mouse.el (mouse-drag-line): When window-resize-pixelwise is
    nil call adjust-window-trailing-edge with suitable arguments
    (Bug#16594).

martin

Message #17 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: pitometsu <at> gmail.com, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Sun, 31 Aug 2025 11:34:25 +0300

> Date: Sun, 31 Aug 2025 09:31:18 +0200
> Cc: 79351 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > According to the manual, window-resize-pixelwise = nil is what you
>  > want.  However, it currently doesn't affect dragging the window border
>  > with the mouse, AFAIU.  Martin, am I right?  This could be a simple
>  > omission.
> 
> You and Stefan wanted mouse dragging to work pixelwise.  See the
> discussion in Bug#16594.
> 
> commit a1a04df94c2cdea0f24733aa9b1892ee7ba50b13
> Author: Eli Zaretskii <eliz <at> gnu.org>
> Date:   Thu Jan 30 19:42:48 2014 +0200
> 
>      Revert last commit in mouse.el.
> 
> commit df1834593692c4103f89de90aaa882a2fb404eb6
> Author: Martin Rudalics <rudalics <at> gmx.at>
> Date:   Thu Jan 30 14:19:19 2014 +0100
> 
>      In mouse-drag-line obey window-resize-pixelwise (Bug#16594).
> 
>      * mouse.el (mouse-drag-line): When window-resize-pixelwise is
>      nil call adjust-window-trailing-edge with suitable arguments
>      (Bug#16594).

That was because of performance issues, right?  I see nothing in that
discussion that objects to the character-level dragging in principle.

I see no reason not to allow that as an option.  Patches welcome.

Message #20 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pitometsu <at> gmail.com, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Mon, 1 Sep 2025 10:37:32 +0200

[Message part 1 (text/plain, inline)]

> That was because of performance issues, right?  I see nothing in that
> discussion that objects to the character-level dragging in principle.
>
> I see no reason not to allow that as an option.  Patches welcome.

I attach a patch supposed to fix your earlier

 According to the manual, window-resize-pixelwise = nil is what you
 want.  However, it currently doesn't affect dragging the window border
 with the mouse, AFAIU.  Martin, am I right?  This could be a simple
 omission.

But it's still sluggish as back in 2014, the mouse cursor moves far
ahead of the lines to drag and it refuses to move a mode line with
'mouse-fine-grained-tracking' non-nil.  Likely remember_mouse_glyph
interferes here.

martin

[drag-line.diff (text/x-patch, attachment)]

Message #23 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: pitometsu <at> gmail.com, martin rudalics <rudalics <at> gmx.at>
Cc: 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Mon, 01 Sep 2025 18:06:00 +0300

> Date: Mon, 1 Sep 2025 10:37:32 +0200
> Cc: pitometsu <at> gmail.com, 79351 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > That was because of performance issues, right?  I see nothing in that
>  > discussion that objects to the character-level dragging in principle.
>  >
>  > I see no reason not to allow that as an option.  Patches welcome.
> 
> I attach a patch supposed to fix your earlier
> 
>   According to the manual, window-resize-pixelwise = nil is what you
>   want.  However, it currently doesn't affect dragging the window border
>   with the mouse, AFAIU.  Martin, am I right?  This could be a simple
>   omission.
> 
> But it's still sluggish as back in 2014, the mouse cursor moves far
> ahead of the lines to drag and it refuses to move a mode line with
> 'mouse-fine-grained-tracking' non-nil.  Likely remember_mouse_glyph
> interferes here.

Thanks.  I hope Yurii will be able to try the patch and see if it
satisfies him.

Message #26 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Mon, 1 Sep 2025 18:08:46 +0300

[Message part 1 (text/plain, inline)]

Thanks a lot for the patch, feel free to let me know which version I could
build and test.

On Mon, Sep 1, 2025 at 6:06 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Mon, 1 Sep 2025 10:37:32 +0200
> > Cc: pitometsu <at> gmail.com, 79351 <at> debbugs.gnu.org
> > From: martin rudalics <rudalics <at> gmx.at>
> >
> >  > That was because of performance issues, right?  I see nothing in that
> >  > discussion that objects to the character-level dragging in principle.
> >  >
> >  > I see no reason not to allow that as an option.  Patches welcome.
> >
> > I attach a patch supposed to fix your earlier
> >
> >   According to the manual, window-resize-pixelwise = nil is what you
> >   want.  However, it currently doesn't affect dragging the window border
> >   with the mouse, AFAIU.  Martin, am I right?  This could be a simple
> >   omission.
> >
> > But it's still sluggish as back in 2014, the mouse cursor moves far
> > ahead of the lines to drag and it refuses to move a mode line with
> > 'mouse-fine-grained-tracking' non-nil.  Likely remember_mouse_glyph
> > interferes here.
>
> Thanks.  I hope Yurii will be able to try the patch and see if it
> satisfies him.
>

[Message part 2 (text/html, inline)]

Message #29 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Mon, 1 Sep 2025 18:09:28 +0300

[Message part 1 (text/plain, inline)]

Thanks a lot for the patch, feel free to let me know which version I could
build and test.

On Mon, Sep 1, 2025 at 6:08 PM Yurii Pytomets <pitometsu <at> gmail.com> wrote:

> Thanks a lot for the patch, feel free to let me know which version I could
> build and test.
>
> On Mon, Sep 1, 2025 at 6:06 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > Date: Mon, 1 Sep 2025 10:37:32 +0200
>> > Cc: pitometsu <at> gmail.com, 79351 <at> debbugs.gnu.org
>> > From: martin rudalics <rudalics <at> gmx.at>
>> >
>> >  > That was because of performance issues, right?  I see nothing in that
>> >  > discussion that objects to the character-level dragging in principle.
>> >  >
>> >  > I see no reason not to allow that as an option.  Patches welcome.
>> >
>> > I attach a patch supposed to fix your earlier
>> >
>> >   According to the manual, window-resize-pixelwise = nil is what you
>> >   want.  However, it currently doesn't affect dragging the window border
>> >   with the mouse, AFAIU.  Martin, am I right?  This could be a simple
>> >   omission.
>> >
>> > But it's still sluggish as back in 2014, the mouse cursor moves far
>> > ahead of the lines to drag and it refuses to move a mode line with
>> > 'mouse-fine-grained-tracking' non-nil.  Likely remember_mouse_glyph
>> > interferes here.
>>
>> Thanks.  I hope Yurii will be able to try the patch and see if it
>> satisfies him.
>>
>
>

[Message part 2 (text/html, inline)]

Message #32 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: rudalics <at> gmx.at, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Mon, 01 Sep 2025 18:54:20 +0300

> From: Yurii Pytomets <pitometsu <at> gmail.com>
> Date: Mon, 1 Sep 2025 18:08:46 +0300
> Cc: martin rudalics <rudalics <at> gmx.at>, 79351 <at> debbugs.gnu.org
> 
> Thanks a lot for the patch, feel free to let me know which version I could build and test.

The master branch, I guess.

Message #35 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Tue, 2 Sep 2025 10:16:55 +0200

[Message part 1 (text/plain, inline)]

> Thanks a lot for the patch, feel free to let me know which version I could
> build and test.

The patch I sent earlier had a thinko (the same as the one from 2014)
which I tried to fix now.  You should be able to apply the attached to
any recent version but I tested with master only.  You don't even have
to build Emacs, just compile and load mouse.el to test it.

Afterwards we'll have to decide whether we want this change to become
the default behavior (and obviously check whether it badly affects any
other instances of line dragging).  Note also, that "characterwise"
dragging does not take face remapping into account.  The size of a
character is always the canonical character size of the respective
frame.

martin

[drag-line.diff (text/x-patch, attachment)]

Message #38 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Tue, 2 Sep 2025 12:11:57 +0300

[Message part 1 (text/plain, inline)]

Tested with the latest stable Emacs.  Really like that behaviour,
didn't notice thank you!

However looks like there's another issue unrelated to the window
splitting: for some reason, during frame resize, despite it going
line-by-line, the window afterwards is slightly cutted and has
slightly less than a whole number height.

On Tue, Sep 2, 2025 at 11:17 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
>  > Thanks a lot for the patch, feel free to let me know which version I could
>  > build and test.
>
> The patch I sent earlier had a thinko (the same as the one from 2014)
> which I tried to fix now.  You should be able to apply the attached to
> any recent version but I tested with master only.  You don't even have
> to build Emacs, just compile and load mouse.el to test it.
>
> Afterwards we'll have to decide whether we want this change to become
> the default behavior (and obviously check whether it badly affects any
> other instances of line dragging).  Note also, that "characterwise"
> dragging does not take face remapping into account.  The size of a
> character is always the canonical character size of the respective
> frame.
>
> martin



-- 
With best regards,
Yurii Pytomets
Haskell developer | Strong solution
For beautiful ideas

[Screenshot from 2025-09-02 11-51-16.png (image/png, attachment)]

Message #41 received at 79351 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79351 <at> debbugs.gnu.org
Subject: Re: bug#79351: 30.2; window-resize-symbollwise
Date: Wed, 3 Sep 2025 09:38:49 +0200

[Message part 1 (text/plain, inline)]

> Tested with the latest stable Emacs.  Really like that behaviour,
> didn't notice thank you!

It's still not as smooth as I want it.  The basic idea is to keep the
mode line as close to the mouse cursor as possible.  This is problematic
since the mouse is usually dragged with constant speed while the mode
line jumps (we could have it snap back at the end of dragging but that's
an annoying effect I'd like to avoid).  And it's particularly tricky
when a user reverts the dragging direction after overshooting.

One aspect the previous patch did not handle was the residue that
results when you have, for example, a character height of 22 pixels and
a mouse move of 18 or 40 pixels gets reported.  In that case I now have
the remaining 18 pixels be handled in the next move.  The results look
better here, please try the attached patch.

> However looks like there's another issue unrelated to the window
> splitting: for some reason, during frame resize, despite it going
> line-by-line, the window afterwards is slightly cutted and has
> slightly less than a whole number height.

You mean to say that a new frame has entire lines and the effect gets
visible only after resizing?  In either case, please file a new bug
report with the screenshot included.  In addition we would have to know:

- The build details as for a standard bug report (Emacs version, toolkit
  and so on).

- The window manager you use.

- The frame geometry in the bad state.  For this purpose do

  M-: (window--dump-frame)

  in that state.  This should get you a buffer *window--dump-frame*
  whose contents might tell what went wrong.

Thanks, martin

[drag-line.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.