From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Nicolas_Despr=C3=A8s?= Newsgroups: gmane.emacs.devel Subject: Re: Prefer to split along the longest edge Date: Sat, 14 Dec 2024 21:10:38 +0100 Message-ID: References: <87r06a3yfg.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000be8b2c0629408cb0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8826"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 14 21:12:14 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tMYUo-0002C5-22 for ged-emacs-devel@m.gmane-mx.org; Sat, 14 Dec 2024 21:12:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMYU0-0004jv-SJ; Sat, 14 Dec 2024 15:11:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tMYTw-0004jT-Rv for emacs-devel@gnu.org; Sat, 14 Dec 2024 15:11:20 -0500 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tMYTu-0001A2-EA for emacs-devel@gnu.org; Sat, 14 Dec 2024 15:11:20 -0500 Original-Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4361e89b6daso19605735e9.3 for ; Sat, 14 Dec 2024 12:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734207076; x=1734811876; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xTyCJGs2h3zPGLkNCPp1s9Fhiw6Kv/FrgHZ2yKcYYiQ=; b=YVKjRwsSUhp1T69QQwqak7BM0p9d8YKneufEshWKug8oEfZr884n99lrDvekx0sTZJ eW1ldZ1yEkhzzyMVtNxmDHAjm8deTqT9x6Aum/emKOs+ubOMw3ZRhkgzvBaIMdLA45lZ Qbl1Kd8G7ttoUONGf/etAIO1zxZ0skp6dRv3UDcofzmaNz/L72Y81TjikjPUfWFpZEpJ anVQQBO38TZwt3dwxw769sfX6BFmSC0N16qDZvzFTwm8mrafgPKf4ydxcTMGtpKdFQeh DjmGVXpNF2Tvh4Z/CT+KRbOGKtVQIdVcaSyg7cGneD0oLpWtsoBzK1vwF6QfXGwpddlR 21Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734207076; x=1734811876; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xTyCJGs2h3zPGLkNCPp1s9Fhiw6Kv/FrgHZ2yKcYYiQ=; b=FB3/69rASbixKIk7lxZ2VY3aRZx3Cw2+j3LVcwC4AMRBR0maS14XdoQN+l57GOZD52 SNzj4FT6u8JCGnKUuWzOQYpwLPN/iCSJkCPm1npfFf7SEfGJGENqjYvsXWlNuryMHzr1 EOdZ+guoHQtTvkYUzt90TYFyapKPGPfxn34EWomdjy6Zs7VxPuZxLbSpXRWUCshe+3U9 RVGnxTqopTArRZG9bqsEnevbPiuG77XmH0JjSdz6UqG4c+jWg3Y/Tly52m0QDqyrjL3Y n9e7yAxjmRtlJMo5BqSfGeSQgEs5b44NjaquVK8Tqkv5ZjQ+p/WGvO6Gk6B4ItVOT3JY vCng== X-Gm-Message-State: AOJu0YxBIe/WxKA+jikhMD8T2DQ+aRAkfm+RyGULXAcr/JZ4lXLuy9+F Gr0/JkmHM9zVRKJ+BUZUMUpUKhH/JgRkpHoPZBy5r+uExijatvc/ZS5x3IXZDSt5rlbuarLXEUE iomIQu2ABLvAJrwCjFybRKfZQE3A= X-Gm-Gg: ASbGnctW9w92CE6ciY/41vK0hz+G8YCjzYJ1ES3wGUWv+gaG9orgX60uFrxuJR5LwbP v7LKBgYJytO4HQRqMiglAsbyvq2v4r4RC5vk0bL8= X-Google-Smtp-Source: AGHT+IH5xOhxT+ICxXb7XQb6SC0IhW0CdVHPfUr/t6ASjuWHdFsOdS2vEMsSAzY5nkUdDttBqE6ecn23CsFzuk9q2oo= X-Received: by 2002:a5d:64ee:0:b0:385:e055:a28d with SMTP id ffacd0b85a97d-3889ad38e4amr5603431f8f.57.1734207076205; Sat, 14 Dec 2024 12:11:16 -0800 (PST) In-Reply-To: <87r06a3yfg.fsf@mail.linkov.net> Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=nicolas.despres@gmail.com; helo=mail-wm1-x333.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326501 Archived-At: --000000000000be8b2c0629408cb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2024 at 7:38=E2=80=AFPM Juri Linkov wrote= : > > Currently, `split-window-sensibly' prefers to split vertically, > > disregarding the shape of the frame. This is a good default when > > Emacs is taller than wider. However, when Emacs is in fullscreen > > (landscape screen layout), splitting vertically is generally not the > > thing to do because there is plenty of space on the right. > > > > Typical scenario: Emacs is in fullscreen; one buffer is open in a windo= w > > covering the entire frame. Another buffer is opened in a second > > window (C-x 4 f). In this case, the split should generally be horizonta= l. > > The attached patch changes `split-window-sensibly' to just try > > spliting the longest edge first. > > I see no symmetry between width and height. > > To make a window usable you need to decide how many columns you need > to fit into the window by customizing split-width-threshold. > > By default it's 160 that means two horizontally split windows > with 80 columns in each that allows a comfortable use of each window. > > OTOH, the window height has less relevance since most of the time > all windows are scrolled vertically. > Thanks for your reply. My proposal is not about questioning the relevance of the split-width-threshold and split-height-threshold. They are perfectly fine to me. I don't want to scroll twice more because of a vertical split, whereas I have the 2/3 of my screen free to show another buffer of code. In this scenario both splits would succeed because the frame dimension exceeds by a lot their respective threshold. My point is about the order in which splits are tried. I would like it to first tries the longest edge. So that if it succeed it is likely to be the direction where there is the more space available. But I understand the bias toward vertical splitting, that's why I added a condition to prioritize vertical split if the width is less than 80. This heuristic could be improved, thought. --000000000000be8b2c0629408cb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 14, 2024 at 7:38= =E2=80=AFPM Juri Linkov <juri@linkov.= net> wrote:
> Currently, `split-window-sensibly' prefers to split vertically,=
> disregarding the shape of the frame.=C2=A0 This is a good default when=
> Emacs is taller than wider.=C2=A0 However, when Emacs is in fullscreen=
> (landscape screen layout), splitting vertically is generally not the > thing to do because there is plenty of space on the right.
>
> Typical scenario: Emacs is in fullscreen; one buffer is open in a wind= ow
> covering the entire frame.=C2=A0 Another buffer is opened in a second<= br> > window (C-x 4 f). In this case, the split should generally be horizont= al.
> The attached patch changes `split-window-sensibly' to just try
> spliting the longest edge first.

I see no symmetry between width and height.

To make a window usable you need to decide how many columns you need
to fit into the window by customizing split-width-threshold.

By default it's 160 that means two horizontally split windows
with 80 columns in each that allows a comfortable use of each window.

OTOH, the window height has less relevance since most of the time
all windows are scrolled vertically.

Thanks for your reply.

My proposal is not about ques= tioning the relevance of the split-width-threshold and split-height-thresho= ld. They are perfectly fine to me.

I don't want to scroll twice more because of a vertical split= , whereas I have the 2/3 of my screen free to show another buffer of code.<= br>

In this scenario both splits would succeed because the frame= dimension exceeds by a lot their respective threshold.

My point is about the order in which splits = are tried. I would like it to first tries the longest edge.

So that if it succeed it is likely to be= the direction where there is the more space available.

But I understand the bias toward vertical sp= litting, that's why I added a condition to prioritize vertical split if= the width is less than 80. This heuristic could be improved, thought.
=

--000000000000be8b2c0629408cb0--