unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: nicolas.despres@gmail.com, juri@linkov.net, emacs-devel@gnu.org
Subject: Re: Prefer to split along the longest edge
Date: Wed, 18 Dec 2024 16:12:56 +0200	[thread overview]
Message-ID: <86ed25m653.fsf@gnu.org> (raw)
In-Reply-To: <89d19d67-cf76-4441-b8d6-c30e6f8118d9@gmx.at> (message from martin rudalics on Wed, 18 Dec 2024 11:05:55 +0100)

> Date: Wed, 18 Dec 2024 11:05:55 +0100
> Cc: nicolas.despres@gmail.com, juri@linkov.net, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > It could be both.  But I firmly object to make this be customizable
>  > _only_ through display-buffer action alists, because that is even less
>  > user-friendly than function values of defcustoms.
> 
> If we make this and other display buffer options a defcustom too, we'd
> have to specify the semantics of that defcustom.  In particular:

To clarify: I was talking only about this particular toggle, not about
"other display-buffer options".  The difference is that those other
options already exist, so removing or redesigning them is not easy at
best, and thus probably isn't worth our while.

> - Should the defcustom hold for any buffer to be displayed?
> 
> - Should it override what the calling program specifies in the ALIST
>    argument.
> 
> - Would a 'display-buffer-alist' entry override it?
> 
> Once these have been resolved, we can easily add defcustoms for most
> options that are currently only available via 'display-buffer-alist'.

I don't necessarily see how the above questions are relevant to the
issue at hand.  AFAIU, the OP asked for a capability to tell Emacs to
split horizontally first instead of vertically.  My interpretation of
that is that this desire is global, for all the use cases.  So a
single global option seems appropriate, and my personal answer to the
above questions would be YES to the first one at least.  As for the
other two: can display-buffer-alist specify the splitting behavior
this today?  If not, I don't see why we should forcibly introduce such
a possibility, which will then require us to consider who can override
whom.  If display-buffer-alist cannot specify splitting, then the
problem with overriding doesn't exist.



  reply	other threads:[~2024-12-18 14:12 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-14 10:05 Prefer to split along the longest edge Nicolas Desprès
2024-12-14 11:30 ` Eli Zaretskii
2024-12-14 11:45   ` Nicolas Desprès
2024-12-14 12:34     ` Eli Zaretskii
2024-12-14 14:06       ` Nicolas Desprès
2024-12-14 14:55         ` Eli Zaretskii
2024-12-14 15:41           ` Nicolas Desprès
2024-12-14 17:16   ` martin rudalics
2024-12-14 17:33     ` Eli Zaretskii
2024-12-14 17:36     ` Eli Zaretskii
2024-12-14 18:35 ` Juri Linkov
2024-12-14 20:10   ` Nicolas Desprès
2024-12-15  7:34     ` Juri Linkov
2024-12-15  9:29       ` Nicolas Desprès
2024-12-16  7:55         ` Juri Linkov
2024-12-16 11:56           ` Nicolas Desprès
2024-12-16 17:14             ` Eli Zaretskii
2024-12-16 17:44               ` Juri Linkov
2024-12-16 19:07                 ` Eli Zaretskii
2024-12-16 19:14                   ` Juri Linkov
2024-12-16 19:53                     ` Eli Zaretskii
2024-12-17  6:12                       ` Nicolas Desprès
2024-12-17  7:40                         ` Juri Linkov
2024-12-17  8:35                           ` Nicolas Desprès
2024-12-17  9:02                             ` martin rudalics
2024-12-17  9:09                               ` Nicolas Desprès
2024-12-17 13:34                               ` Eli Zaretskii
2024-12-18 10:05                                 ` martin rudalics
2024-12-18 14:12                                   ` Eli Zaretskii [this message]
2024-12-18 16:24                                     ` martin rudalics
2024-12-18 16:55                                       ` Eli Zaretskii
2024-12-18 17:41                                         ` martin rudalics
2024-12-18 18:41                                           ` Eli Zaretskii
2024-12-18 19:13                                             ` martin rudalics
2024-12-19  7:06                                           ` Juri Linkov
2024-12-18 17:25                                       ` Juri Linkov
2024-12-17  6:06               ` Nicolas Desprès
2024-12-17 12:52                 ` Eli Zaretskii
2024-12-17 12:59                 ` Eli Zaretskii
2024-12-17 13:12                   ` Robert Pluim
2024-12-18 21:08                     ` Nicolas Desprès
2024-12-19  6:39                       ` Eli Zaretskii
2024-12-19  8:52                         ` martin rudalics
2024-12-19  9:21                           ` Eli Zaretskii
2024-12-19 16:20                             ` Nicolas Desprès
2024-12-20  9:03                               ` martin rudalics
2024-12-20 14:43                                 ` Nicolas Desprès
2024-12-20 15:05                                   ` Robert Pluim
2024-12-16 17:32             ` Juri Linkov
2024-12-17  9:01               ` martin rudalics
2024-12-17 13:32                 ` Eli Zaretskii
2024-12-17  1:51             ` Liu Hui
2024-12-17  7:43               ` Juri Linkov
2024-12-17  8:27                 ` Nicolas Desprès
2024-12-17  8:26               ` Nicolas Desprès
2024-12-16 17:15           ` [External] : " Drew Adams
2024-12-17  8:39             ` Nicolas Desprès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ed25m653.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --cc=nicolas.despres@gmail.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).