all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 67249@debbugs.gnu.org
Subject: bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`
Date: Fri, 24 Nov 2023 10:05:20 +0100	[thread overview]
Message-ID: <488b181f-c74e-d97b-b168-a602158c3e7b@gmx.at> (raw)
In-Reply-To: <jwvlean7ulh.fsf-monnier+emacs@gnu.org>

 > Here's a first candidate patch.
 >
 > I introduced a new function `display-buffer--pop-up-frame` so as to
 > ignore `inhibit-new-frame` as a last resort.

Good idea.

 > I also modified `display-buffer--other-frame-action` to use
 > `display-buffer--pop-up-frame`, because it seems this is used only(?) in
 > response to an explicit user request where the user does expect a new
 > frame (like `C-x 5 b`) and so it seems to make sense to override even an
 > `inhibit-new-frame` coming from `display-buffer-alist`.

 >  (defvar display-buffer--other-frame-action
 >    '((display-buffer-reuse-window
 > -     display-buffer-pop-up-frame)
 > +     display-buffer--pop-up-frame)
 >      (reusable-frames . 0)
 >      (inhibit-same-window . t))

This one is messy anyway but I never tried to tinker with it.  After
all, "0" means to probe any frame around _including_ the selected one.
It probably should call 'display-buffer-use-some-frame' and maybe also
'display-buffer-use-least-recent-window' with a suitable 'lru-frames'
entry.  Just that our FRAMES argument nomenclature does not allow to
exclude the selected frame from the list of frames to probe or return.

 > +(defun display-buffer--pop-up-frame (buffer alist)
 > +  "Like `display-buffer--pop-up-frame' but ignores `inhibit-new-frame'.

This seems to have an extra "-".

 > PS: Am I the only one who finds it confusing how some functions
 > named `display-buffer-<foo>` are meant to be used from the ACTIONs
 > (i.e. from within `display-buffer`) while others are implemented on top
 > of `display-buffer` (and thus should not be used within ACTIONS)?
 > Could we try and find a clear naming convention to distinguish the two,
 > or am I even more confused than I thought and several of those functions
 > can be used either way?

Do you mean 'display-buffer-override-next-command' and
'display-buffer-record-window'?  As for the latter, the reason was that
applications might want to call this in their code for recording the
window used so it's not meant to be strictly window.el internal.  If you
mean something else, please give one or two examples of such confusing
functions.

martin






  reply	other threads:[~2023-11-24  9:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 21:41 bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-18  8:36 ` martin rudalics
2023-11-19  3:52   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-19 10:35     ` martin rudalics
2023-11-19 14:57       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-20  9:15         ` martin rudalics
2023-11-20 13:33           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-21 17:14             ` martin rudalics
2023-11-21 19:09               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-22  8:02                 ` martin rudalics
2023-11-22 16:03                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23  9:59                     ` martin rudalics
2023-11-24  2:52                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-24  9:05                         ` martin rudalics [this message]
2023-11-24 13:51                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-24 16:25                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25  9:00                               ` martin rudalics
2023-11-25 14:36                                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-03 19:06                                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-04  7:23                                     ` martin rudalics
2023-12-09 22:29                                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 22:40                                         ` Drew Adams
2023-12-09 22:52                                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 23:17                                             ` Drew Adams
2023-12-10  6:00                                           ` Eli Zaretskii
2023-12-10 16:28                                             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-10 21:46                                             ` Drew Adams
2023-12-10  5:53                                         ` Eli Zaretskii
2023-12-10 17:16                                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-11 17:13                                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-11 22:14                                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-16 18:16                                                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25  9:00                             ` martin rudalics
2023-11-25 14:37                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

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

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

  git send-email \
    --in-reply-to=488b181f-c74e-d97b-b168-a602158c3e7b@gmx.at \
    --to=rudalics@gmx.at \
    --cc=67249@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.