GNU bug report logs - #48493
28.0.50; quit-window doesn't work

Previous Next

Package: emacs;

Reported by: Sujith Manoharan <sujith.wall <at> gmail.com>

Date: Tue, 18 May 2021 03:36:01 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #36 received at 48493 <at> debbugs.gnu.org (full text, mbox):

From: pillule <pillule <at> riseup.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: pillule <pillule <at> riseup.net>, Sujith Manoharan <sujith.wall <at> gmail.com>,
 48493 <at> debbugs.gnu.org
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Tue, 25 May 2021 13:01:05 +0000
martin rudalics <rudalics <at> gmx.at> writes:

>> Then I suppose that the dedicated window parameter must be 
>> restored
>> after a kill-buffer accordingly; this solve the previous test 
>> but
>> ask for more modifications.
>
> Who makes any of these buffers dedicared?

All windows created by `display-buffer-in-side-window' have the 
state
(dedicated . side)

Tiers libraries such as the module popup from Doom emacs come at 
this
subject with the rule :

--quitting/killing a buffer in a side window,
always delete its window--
(it is done with a local value of kill-buffer-hook installed from
their own `display-buffer-alist')

instead of the rule :

--quitting/killing a buffer in any window,
1 switch to its previous buffer
2 delete the window if no available
3 switch to another buffer if the window is not deletable--

Which is what I think you are asking and IMHO ask to deal with the
dedicated window state to not cripple side-windows.

>> I can modify to `switch-to-prev-buffer' (and its sibling
>> `switch-to-prev-buffer') to return nil instead of the current 
>> buffer;
>> however the result is the same : the window rest in place with 
>> an
>> undesired buffer inside.
>> Note that we may want that anyway if it can solve the cases 
>> where
>> `quit-restore-window' display the same buffer again.
>>
>> I am still looking to find what may be messing the prev-buffers 
>> list.
>
> Try to experiment with an idiom like
>
>       (if prev-buffer
>           ;; If a previous buffer exists, try to switch to it. 
>           If that
>           ;; fails for whatever reason, try to delete the 
>           window.
>           (unless (switch-to-prev-buffer window bury-or-kill)
>             (window--delete window nil (eq bury-or-kill 'kill)))
>         ;; If no previous buffer exists, try to delete the 
>         window.  If
>         ;; that fails for whatever reason, try to switch to some 
>         other
>         ;; buffer.
>         (unless (window--delete window nil (eq bury-or-kill 
>         'kill))
>           (switch-to-prev-buffer window bury-or-kill)))

Thanks for the snippet, I think I am confused by this window 
dedication,
please help me to clarify my mind before I try to implement a 
solution
with or without the dedicated window state.

-- 




This bug report was last modified 3 years and 337 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.