GNU bug report logs - #80053
30.1.90; split-window-preferred-direction=longest should be based on pixel width/height

Previous Next

To reply to this bug, email your comments to 80053 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: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1.90; split-window-preferred-direction=longest should be based
 on pixel width/height
Date: Mon, 22 Dec 2025 10:59:24 -0500

split-window-preferred-direction longest is described as:

  If set to ‘longest’, the first direction tried depends on the frame
  shape: in landscape orientation it will be like ‘horizontal’, but in
  portrait it will be like ‘vertical’.  Basically, the longest of the
  two dimension is split first.

The frame is assumed to be "landscape" if (> (frame-width)
(frame-height)), and portrait otherwise.

But that's not right: most frames in portrait orientation still have (>
(frame-width) (frame-height)) because those are in terms of characters,
and characters themselves have greater "height" than "width".  This bug
means 'longest currently causes a regression for users of portrait
frames.

We should be using frame-pixel-width and frame-pixel-height in graphical
frames.  But it's not clear what to use in text frames.  Thoughts?


In GNU Emacs 30.1.90 (build 90, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2025-12-04 built on
 igm-qws-u22796a
Repository revision: 88878f209ee0f1699952b1ba5fb829c502f5959f
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure --with-x-toolkit=lucid --without-gpm --without-gconf
 --without-selinux --without-imagemagick --with-modules --with-gif=no
 --with-cairo --with-rsvg --without-compress-install --with-tree-sitter
 --with-native-compilation=aot
 PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

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

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 80053 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#80053: 30.1.90; split-window-preferred-direction=longest
 should be based on pixel width/height
Date: Mon, 22 Dec 2025 20:29:57 +0200

> split-window-preferred-direction longest is described as:
>
>   If set to ‘longest’, the first direction tried depends on the frame
>   shape: in landscape orientation it will be like ‘horizontal’, but in
>   portrait it will be like ‘vertical’.  Basically, the longest of the
>   two dimension is split first.
>
> The frame is assumed to be "landscape" if (> (frame-width)
> (frame-height)), and portrait otherwise.
>
> But that's not right: most frames in portrait orientation still have (>
> (frame-width) (frame-height)) because those are in terms of characters,
> and characters themselves have greater "height" than "width".  This bug
> means 'longest currently causes a regression for users of portrait
> frames.
>
> We should be using frame-pixel-width and frame-pixel-height in graphical
> frames.  But it's not clear what to use in text frames.  Thoughts?

tab-bar.el copes with this discrepancy using such customization:
the first element of the list in 'tab-bar-auto-width-max' defines
the width in pixels for GUI frames, whereas the second element of the list
is the width in characters on TTY frames.  This means that to support
both pixels and characters, we need to slightly complicate the options.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 80053 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#80053: 30.1.90; split-window-preferred-direction=longest
 should be based on pixel width/height
Date: Tue, 23 Dec 2025 12:31:10 +0000

Hello,

On Mon 22 Dec 2025 at 10:59am -05, Spencer Baugh wrote:

> We should be using frame-pixel-width and frame-pixel-height in
> graphical frames.

I don't have much hands-on user experience with these issues because my
frames are always either my whole monitor or a portrait-shaped half of
it.

But I wouldn't have thought your last claim here is obvious.
Isn't it the display of characters we care about?  IOW if a frame is
portrait with respect to characters, then wouldn't we want to always
split it vertically?

I'm certainly open to being convinced -- could you say more about why
you think it's pixels that matter?

> But it's not clear what to use in text frames.

Even if we can sometimes query the terminal for a pixel width (I don't
know), we won't always be able to do so, so going by characters would
probably result in more consistent behaviour.  The most important thing
to avoid seems to be the user expecting a command will split the window
one way and then it doing it the other.

-- 
Sean Whitton

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: martin rudalics <rudalics <at> gmx.at>, 80053 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#80053: 30.1.90; split-window-preferred-direction=longest
 should be based on pixel width/height
Date: Tue, 23 Dec 2025 10:56:09 -0500

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> On Mon 22 Dec 2025 at 10:59am -05, Spencer Baugh wrote:
>
>> We should be using frame-pixel-width and frame-pixel-height in
>> graphical frames.
>
> I don't have much hands-on user experience with these issues because my
> frames are always either my whole monitor or a portrait-shaped half of
> it.
>
> But I wouldn't have thought your last claim here is obvious.
> Isn't it the display of characters we care about?  IOW if a frame is
> portrait with respect to characters, then wouldn't we want to always
> split it vertically?

Just to be clear:

split-window-sensibly absolutely needs to use frame-width and
frame-height (not pixel-width/pixel-height) to decide whether vertical
and horizontal splits are *possible*.

However, if both kinds of splits are possible, how does
split-window-sensibly decide which kind of split to make?
split-window-preferred-direction controls this.  It can make this
decision using any heuristics, including using frame-pixel-width and
frame-pixel-height.

> I'm certainly open to being convinced -- could you say more about why
> you think it's pixels that matter?

I think it is best demonstrated by example.  The portrait frames you
use: would you prefer them to split vertically or horizontally?
Assuming they have enough width and height to split in either direction,
that is, which you can ensure by zooming out.

My assumption is that you'd prefer a portrait frame to be split
vertically.  Or at least, that's what split-window-preferred-direction
is supposed to ensure.

If you open up one of the portrait frames you use and run (list
(frame-height) (frame-width)) I expect you'll see that even though they
are portrait frames, they almost certainly have higher width than height
(unless they are extremely skinny).  So they'll only split horizontally,
not vertically.

Sure, they're "portrait with respect to characters" but I don't think
that's a useful concept, and it's not one we use anywhere else AFAIK.
frame-width and frame-height simply can't be compared with < to get a
valid result, they're not the same unit.  frame-pixel-width and
frame-pixel-height are the same unit and can be compared with <.

>> But it's not clear what to use in text frames.
>
> Even if we can sometimes query the terminal for a pixel width (I don't
> know), we won't always be able to do so, so going by characters would
> probably result in more consistent behaviour.  The most important thing
> to avoid seems to be the user expecting a command will split the window
> one way and then it doing it the other.

If you play around with the sizes of frames where (< (frame-height)
(frame-width)) is true and where it is false, I think you'll find that
it is not at all visually obvious how skinny a frame must be to have
that be false.  I don't think that's predictable or consistent behavior.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Spencer Baugh <sbaugh <at> janestreet.com>,  martin rudalics
 <rudalics <at> gmx.at>,  80053 <at> debbugs.gnu.org,  juri <at> linkov.net
Subject: Re: bug#80053: 30.1.90; split-window-preferred-direction=longest
 should be based on pixel width/height
Date: Wed, 24 Dec 2025 13:06:08 +0000

Hello,

On Tue 23 Dec 2025 at 10:56am -05, Spencer Baugh wrote:

> Just to be clear:
>
> split-window-sensibly absolutely needs to use frame-width and
> frame-height (not pixel-width/pixel-height) to decide whether vertical
> and horizontal splits are *possible*.
>
> However, if both kinds of splits are possible, how does
> split-window-sensibly decide which kind of split to make?
> split-window-preferred-direction controls this.  It can make this
> decision using any heuristics, including using frame-pixel-width and
> frame-pixel-height.
>
>> I'm certainly open to being convinced -- could you say more about why
>> you think it's pixels that matter?
>
> I think it is best demonstrated by example.  The portrait frames you
> use: would you prefer them to split vertically or horizontally?
> Assuming they have enough width and height to split in either direction,
> that is, which you can ensure by zooming out.
>
> My assumption is that you'd prefer a portrait frame to be split
> vertically.  Or at least, that's what split-window-preferred-direction
> is supposed to ensure.
>
> If you open up one of the portrait frames you use and run (list
> (frame-height) (frame-width)) I expect you'll see that even though they
> are portrait frames, they almost certainly have higher width than height
> (unless they are extremely skinny).  So they'll only split horizontally,
> not vertically.
>
> Sure, they're "portrait with respect to characters" but I don't think
> that's a useful concept, and it's not one we use anywhere else AFAIK.
> frame-width and frame-height simply can't be compared with < to get a
> valid result, they're not the same unit.  frame-pixel-width and
> frame-pixel-height are the same unit and can be compared with <.
>
>>> But it's not clear what to use in text frames.
>>
>> Even if we can sometimes query the terminal for a pixel width (I don't
>> know), we won't always be able to do so, so going by characters would
>> probably result in more consistent behaviour.  The most important thing
>> to avoid seems to be the user expecting a command will split the window
>> one way and then it doing it the other.
>
> If you play around with the sizes of frames where (< (frame-height)
> (frame-width)) is true and where it is false, I think you'll find that
> it is not at all visually obvious how skinny a frame must be to have
> that be false.  I don't think that's predictable or consistent behavior.

This is very convincing, thank you.  Let's implement something like this
for the case where the thresholds are met.

-- 
Sean Whitton

Previous Next

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