all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>, Tom Gillespie <tgbugs@gmail.com>
Cc: emacs-devel@gnu.org, larsi@gnus.org
Subject: Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames
Date: Mon, 6 Feb 2023 11:01:20 +0100	[thread overview]
Message-ID: <fc2970cc-eac7-e05e-f14e-6c9a2e588d63@gmx.at> (raw)
In-Reply-To: <a37e3600-c40b-e9c6-7893-b3a9a580dfb1@gmx.at>

 > (2) The current version of 'window-bump-use-time' changes the semantics
 > of "least recently used window" without even mentioning that anywhere.
 > For example, this code in sql.el
 >
 >      (let ((one-win (eq (selected-window)
 >                         (get-lru-window))))
 >
 > will conclude that there is only one window even if another window
 > recently created by 'display-buffer-use-least-recent-window' exists.  I
 > have no idea how 'get-mru-window' could be affected.
 >
 > This is a grave bug.

This statement is much too harsh.  The "use time" concept is inherently
flawed ever since it was conceived and it's unlikely that we will ever
be able to fix that.

For example, the following form

(with-selected-window (split-window nil nil t)
   (eq (get-lru-window) (selected-window)))

will consider the selected window the least recently used one which
doesn't make sense.  One now might think that the "least recently used
window" is well-defined outside the scope of 'with-selected-window' but
even that is false.  Consider

(let (window)
   (with-selected-window (setq window (split-window nil nil t))
     (select-window (split-window window nil t)))
   (eq (selected-window) (get-mru-window)))

Here the window selected outside the scope of any window excursion is no
more the most recently used one.

This means that any code like the above cited

 >      (let ((one-win (eq (selected-window)
 >                         (get-lru-window))))

is based on the false assumption that if the selected window is the
least recently used one, this is tantamount to saying that the selected
window is alone on its frame.

Given the number of 'display-buffer' calls that occur within window
excursions like 'save-selected-window', 'with-selected-window' and the
like, there's no wonder that many of them have produced unexpected
results in the past.  To cite but a few, all of ‘next-error-no-select’,
‘xref--show-location’, ‘widget-button--check-and-call-button’,
‘table-generate-source’, ‘mail-recover’, ‘occur-mode-display-occurrence’
cannot hold apart the selected window from the most recently used one
when running 'display-buffer-use-some-window'.

What looks even more disturbing is that these functions are often
supposed to use a window that is not the selected one.  But for
'display-buffer' the selected window is the one temporarily selected by
these functions and not the one that will be selected after the temporal
selection has been left and the final result in form of a displayed
buffer is presented.  Which obviously means that all action functions
called by 'display-buffer' that deal with the selected window and its
avoidance via an 'inhibit-same-window' action alist entry are affected.

Consider

(with-selected-window (split-window)
   (display-buffer "*Messages*"))

*Messages* will be displayed in the upper window and that window will be
the selected one.  Hardly what 'display-buffer' is advertised to do.

But this also means that code bumping a window's use time can do that
any which way it likes.  There is no invariant that code should try to
preserve.  Although it might be a good idea to not bump any window's use
time in a state where the selected window's use time does not equal the
value of window_select_count as in the version below.

DEFUN ("window-bump-use-time", Fwindow_bump_use_time,
        Swindow_bump_use_time, 0, 1, 0,
        doc: /* Mark WINDOW as most recently used after the selected window.
WINDOW must specify a live window.

If WINDOW is not selected and the selected window has the highest use
time of all windows, set the use time of WINDOW to that of the selected
window, increase the use time of the selected window by one and return
the new use time of WINDOW.  Otherwise, do nothing and return nil.  */)
   (Lisp_Object window)
{
   struct window *w = decode_live_window (window);
   struct window *sw = XWINDOW (selected_window);

   if (w != sw && sw->use_time == window_select_count)
     {
       w->use_time = window_select_count;
       sw->use_time = ++window_select_count;

       return make_fixnum (w->use_time);
     }
   else
     return Qnil;
}

martin

      parent reply	other threads:[~2023-02-06 10:01 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
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 [this message]

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=fc2970cc-eac7-e05e-f14e-6c9a2e588d63@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 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.