unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: tgbugs@gmail.com, emacs-devel@gnu.org, larsi@gnus.org
Subject: Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames
Date: Wed, 1 Feb 2023 19:33:19 +0100	[thread overview]
Message-ID: <5d9d2bc5-3e2a-b4fd-413f-4595a3d8a1e3@gmx.at> (raw)
In-Reply-To: <83lelhz3o9.fsf@gnu.org>

 > Is this related to display-buffer-use-least-recent-window and/or
 > window-bump-use-time?  Or is this another set of issues?

It's another set of issues loosely related to
'display-buffer-use-least-recent-window'.  I found it because I tried to
understand why that function did not always return the LRU window.  See
my other mail to Tom.

 > Would it be possible to modify the effect of
 > display-buffer-avoid-small-windows so that it works via the
 > window-min-height alist entry?

No.  'window-min-height' so far is honored only in functions of the
'display-buffer-in-direction' type because there it's easy to tell which
window should have that property.  It's not used in 'get-lru-window'
because that function is not used for buffer display alone.  As a rule,
buffer display options should never show up in functions that can be
used in another context.

We could give 'get-lru-window' an additional ALIST argument which would
indicate that it was indirectly called by 'display-buffer'.  I wouldn't
like it and I don't think we would be able to figure out all the
consequences in due time.  So we need a 'get-lru-window' clone that can
be used by buffer display and takes only an ALIST as argument and
nothing else.

'display-buffer-avoid-small-windows' is an attempt to reintroduce a
concept we tried to abandon many years ago.  It's inherently like
'pop-up-windows' where applications and users fought each other by
setting or binding that variable to their like with undefined outcome.

We tried to stop such fighting by giving users options like
'display-buffer-alist' and 'display-buffer-base-action' and giving
applications the ACTION argument with clear precedence rules.  There's
no precedence rule for 'display-buffer-avoid-small-windows'.

martin



  reply	other threads:[~2023-02-01 18:33 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27  5:17 [PATCH] Fix display-buffer-use-some-window to honor reusable-frames Tom Gillespie
2023-01-27  5:25 ` Tom Gillespie
2023-01-27  6:19   ` Tom Gillespie
2023-01-27 13:03     ` Eli Zaretskii
2023-01-28 10:46       ` martin rudalics
2023-01-28 11:12         ` Eli Zaretskii
2023-01-28 15:35           ` martin rudalics
2023-01-28 16:02             ` Eli Zaretskii
2023-01-29 17:39               ` martin rudalics
2023-01-29 18:41                 ` Eli Zaretskii
2023-01-29 18:50                   ` Tom Gillespie
2023-01-30 16:43                   ` martin rudalics
2023-01-30 17:38                     ` Eli Zaretskii
2023-01-30 17:57                       ` martin rudalics
2023-01-30 18:04                         ` Eli Zaretskii
2023-01-31  8:45                           ` martin rudalics
2023-01-31 14:01                             ` Eli Zaretskii
2023-02-01 10:45                               ` martin rudalics
2023-02-01 17:38                                 ` Eli Zaretskii
2023-02-01 18:33                                   ` martin rudalics [this message]
2023-01-28 19:04         ` Tom Gillespie
2023-01-28 20:01           ` Tom Gillespie
2023-01-29 17:39             ` martin rudalics
2023-01-29 19:02               ` Tom Gillespie
2023-01-30 16:44                 ` martin rudalics
2023-01-30 17:43                   ` Tom Gillespie
2023-01-30 17:58                     ` martin rudalics
2023-01-30 19:40                       ` Tom Gillespie
2023-01-30 22:45                         ` Tom Gillespie
2023-01-31  8:46                           ` martin rudalics
2023-01-31 18:38                             ` Tom Gillespie
2023-02-01  9:08                               ` martin rudalics
2023-02-01 17:19                                 ` Tom Gillespie
2023-02-01 18:32                                   ` martin rudalics
2023-02-02 16:39                                     ` martin rudalics
2023-02-02 19:57                                       ` Tom Gillespie
2023-02-03  9:09                                         ` martin rudalics
2023-02-11 15:44                                           ` Eli Zaretskii
2023-02-11 18:15                                           ` Tom Gillespie
2023-02-12  9:33                                             ` martin rudalics
2023-02-18 17:46                                               ` Eli Zaretskii
2023-02-20  9:03                                                 ` martin rudalics
2023-02-20 11:55                                                   ` Eli Zaretskii
2023-02-20 18:14                                                     ` martin rudalics
2023-02-21 12:02                                                       ` Eli Zaretskii
2023-01-31  8:46                         ` martin rudalics
2023-01-29 17:48         ` Juri Linkov
2023-01-29 18:48           ` Eli Zaretskii
2023-02-06 10:01         ` martin rudalics

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=5d9d2bc5-3e2a-b4fd-413f-4595a3d8a1e3@gmx.at \
    --to=rudalics@gmx.at \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=tgbugs@gmail.com \
    /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).