unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 59862@debbugs.gnu.org
Subject: bug#59862: quit-restore per window buffer
Date: Thu, 11 Jul 2024 09:47:27 +0300	[thread overview]
Message-ID: <86a5ioo269.fsf@mail.linkov.net> (raw)
In-Reply-To: <61c4f245-3dd8-4e24-9c84-7ddd4cfe3c49@gmx.at> (martin rudalics's message of "Wed, 10 Jul 2024 11:16:24 +0200")

>> But there is no *scratch* in the list of previous buffers for 'C-x t t C-h i'
>> (that can be confirmed when tab-line is enabled), so the user won't expect
>> to show *scratch*.  And indeed the frame case doesn't show *scratch*.
>
> 'window--display-buffer' resets that window's previous buffers here
>
>     (when (memq type '(window frame tab))
>       (set-window-prev-buffers window nil))
>
> In the "window" and "frame" case these are actually not needed because
> when making a new window (on the same or a new frame), that window's
> previous buffers are automatically set to nil - by make_window in the
> release version and by the allocation routine with my patch.  I reset
> them just to make sure.  When you show *info* in an already existing
> window, that window's previous buffers are not reset.  So the presence
> of "tab" in the form above is not entirely correct in this regard.

I checked that prev-buffers is nil in both frame and tab cases,
so everything is correct here.

>> I hoped that it would be possible for the tab case to do the same,
>> but I don't know how the frame case is handled to do the right thing.
>
> In 'quit-restore-window' you count the windows with a 'quit-restore'
> parameter.  In the scenario at hand this gives 2 so you don't close the
> tab.  If you told me in detail what this counting is supposed to
> accomplish, I might be able to help you.

'seq-count' with (window-parameter w 'quit-restore) is intended to be
equivalent to (frame-root-window window) in the frame case, and even better.
So the problem is not here.

The difference between frame and tab case is that the frame branch
calls 'window--delete' that decides whether to delete the frame,
or just delete the window.  But in the tab case it either
closes the tab, or does nothing.  So in the tab case
it should call 'window--delete' as well, that will decide
whether to close the tab, or just delete the window.

Then 'window--delete' should do something like this:

   (unless (and dedicated-only (not (window-dedicated-p window)))
     (let ((deletable (window-deletable-p window)))
       (cond
+       ((eq deletable 'tab)
+        (tab-bar-close-tab)
+        'tab)
        ((eq deletable 'frame)
 	(let ((frame (window-frame window)))
 	  (cond

Then maybe 'seq-count' with (window-parameter w 'quit-restore)
should be moved to 'window-deletable-p'.





  reply	other threads:[~2024-07-11  6:47 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06 17:32 bug#59862: quit-restore per window buffer Juri Linkov
2024-06-02  6:45 ` Juri Linkov
2024-06-03  9:34   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-03  9:53     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-03 16:09       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04  6:53         ` Juri Linkov
2024-06-05 16:56           ` Juri Linkov
2024-06-11  6:52           ` Juri Linkov
2024-06-12  8:57             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-13  6:47               ` Juri Linkov
2024-06-13  8:21                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-14 17:35                   ` Juri Linkov
2024-06-15  8:41                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-16 16:50                       ` Juri Linkov
2024-06-17 14:48                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-08 16:49                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-09  6:58                           ` Juri Linkov
2024-07-09  8:52                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-10  6:50                               ` Juri Linkov
2024-07-10  9:16                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-11  6:47                                   ` Juri Linkov [this message]
2024-07-11  8:36                                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-12  6:54                                       ` Juri Linkov
2024-07-12  8:20                                         ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-14  7:49                                           ` Juri Linkov
2024-07-15  7:32                                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-16  6:09                                               ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-16  6:09                                               ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                                               ` <87frs9kgve.fsf@>
2024-07-16  8:22                                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-16 22:14                                                   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-16 22:14                                                   ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                                                   ` <871q3tc7da.fsf@>
2024-07-17  9:23                                                     ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-30  8:20                                             ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-31 17:30                                               ` Juri Linkov
2024-08-01  6:37                                                 ` Juri Linkov
2024-08-01  7:50                                                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-01  7:49                                                 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-01 16:01                                                   ` Juri Linkov

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=86a5ioo269.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=59862@debbugs.gnu.org \
    --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).