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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48493 in the body.
You can then email your comments to 48493 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Sujith Manoharan <sujith.wall <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; quit-window doesn't work
Date: Tue, 18 May 2021 08:51:40 +0530

quit-window doesn't work properly with the master branch.

To see the issue with emacs -Q, in any git repo:

* C-x v L
* C-x 1 (if the screen is split).
* Hitting 'q' now doesn't close the window.

Looks like commit 0a681590268a4039f95a5a919b6b6d4f4e880d4c is
the problem.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2021-05-18 built on comp-lnx
Repository revision: aff87e5d04de9ac59359ed29ca59483fc10d31ea
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr/local --enable-link-time-optimization
 --with-sound=no --without-libsystemd --without-harfbuzz
 --without-m17n-flt --without-libotf --without-lcms2
 --with-x-toolkit=lucid --without-dbus --without-gsettings
 --without-selinux --without-modules --without-gpm --without-cairo
 'CFLAGS=-O2 -march=native''

Configured features:
ACL FREETYPE GIF GLIB GMP GNUTLS JPEG JSON LIBXML2 NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XFT
XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_IN.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  dired-omit-mode: t
  save-place-mode: t
  savehist-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: 1
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
~/dev/elisp/dictionary-el/dictionary hides /usr/local/share/emacs/28.0.50/lisp/net/dictionary

Features:
(shadow face-remap mu4e mu4e-org mu4e-main mu4e-view mu4e-view-old
mu4e-view-common thingatpt mu4e-headers mu4e-compose mu4e-context
mu4e-draft mu4e-actions rfc2368 smtpmail mu4e-mark mu4e-proc mu4e-utils
doc-view jka-compr image-mode exif mu4e-lists mu4e-message shr kinsoku
svg xml dom browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse url-vars flow-fill
org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote
org-src ob-comint org-pcomplete pcomplete comint ansi-color org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp
ob-core ob-eval org-table ol org-keys org-compat advice org-macs
org-loaddefs format-spec cal-menu calendar cal-loaddefs mule-util
mailcap hl-line mu4e-vars mu4e-meta add-log log-view pcvs-util vc-mtn
vc-hg vc-git diff-mode easy-mmode vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs vc vc-dispatcher dired-aux nswbuff eieio-opt cl-extra speedbar
ezimage dframe find-func shortdoc help-fns radix-tree help-mode emacsbug
message rmc puny rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils edmacro kmacro cl-loaddefs cl-lib xcscope ring ido
seq byte-opt gv bytecomp byte-compile cconv dired-x dired dired-loaddefs
saveplace savehist iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar
mouse jit-lock font-lock syntax font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads inotify dynamic-setting font-render-setting x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 151859 9119)
 (symbols 48 16246 5)
 (strings 32 57927 2771)
 (string-bytes 1 1891100)
 (vectors 16 31514)
 (vector-slots 8 344237 13676)
 (floats 8 170 151)
 (intervals 56 1810 15)
 (buffers 992 14))

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

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

[Message part 1 (text/plain, inline)]

> quit-window doesn't work properly with the master branch.
>
> To see the issue with emacs -Q, in any git repo:
>
> * C-x v L
> * C-x 1 (if the screen is split).
> * Hitting 'q' now doesn't close the window.
>
> Looks like commit 0a681590268a4039f95a5a919b6b6d4f4e880d4c is
> the problem.

Right.  Can you try the attached patch?  pillule, please also have a
look into this.

Thanks for the report, martin

[quit-restore-window.diff (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Sujith Manoharan <sujith.wall <at> gmail.com>
Cc: pillule <pillule <at> riseup.net>, 48493 <at> debbugs.gnu.org
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Tue, 18 May 2021 15:31:17 +0200

> The patch fixes the issue. Thanks.

Thanks for checking.  Unless pillule has a better idea I'll install
that.

martin

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

From: Sujith Manoharan <sujith.wall <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: pillule <pillule <at> riseup.net>, 48493 <at> debbugs.gnu.org
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Tue, 18 May 2021 15:53:31 +0530

martin rudalics <rudalics <at> gmx.at> writes:
> Right.  Can you try the attached patch?  pillule, please also have a
> look into this.

The patch fixes the issue. Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Sujith Manoharan <sujith.wall <at> gmail.com>
Cc: pillule <pillule <at> riseup.net>, 48493 <at> debbugs.gnu.org
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Wed, 19 May 2021 09:43:26 +0200

;; tags 48493 fixed
;; close 48493 28.1
;; quit

> The patch fixes the issue. Thanks.

Installed and bug marked as done.

Thanks again for the report, martin

Message #24 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: Mon, 24 May 2021 14:53:21 +0000

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

>  > Looks like commit 0a681590268a4039f95a5a919b6b6d4f4e880d4c is
>  > the problem.

Sorry about that.

> Right.  Can you try the attached patch?  pillule, please also 
> have a
> look into this.

I think there is still edges cases :

with emacs -Q

;; set some rules
(setq display-buffer-alist
    '(("\\*\\(Backtrace\\)\\*"
      (display-buffer-in-side-window)
      (window-height . 0.2)
      (side . bottom))
      ("\\*\\(Messages\\)\\*"
      (display-buffer-in-side-window)
      (window-height . 0.2)
      (side . bottom))))

;; display the *Messages* buffer
(view-echo-area-messages)

;; trigger a logical error to display the *Backtrace* buffer
(> vim emacs)

;; trigger a quit-restore-window by calling kill-buffer in a 
  dedicated window
(kill-buffer (get-buffer "*Backtrace*"))
;; the dedicated property has been cleaned from the window,
;; yet *Messages* is displayed in place of this window !
(kill-buffer (get-buffer "*Messages*"))
;; calling kill-buffer in a non-dedicated window,
;; does not trigger quit-restore-window anymore
;; resulting in an undesirable buffer being displayed in place.


What is the desired behavior of a dedicated window here ?
Must *Messages* be displayed after we killed *Backtrace* in the 
first place ?
I am suspecting that the locale value of `kill-buffer-hook' in 
*Backtrace* is interfering with this test but I have difficulties 
to find its human readable form.

-- 

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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: Mon, 24 May 2021 18:51:18 +0200

> I think there is still edges cases :
>
> with emacs -Q
>
> ;; set some rules
> (setq display-buffer-alist
>      '(("\\*\\(Backtrace\\)\\*"
>        (display-buffer-in-side-window)
>        (window-height . 0.2)
>        (side . bottom))
>        ("\\*\\(Messages\\)\\*"
>        (display-buffer-in-side-window)
>        (window-height . 0.2)
>        (side . bottom))))
>
> ;; display the *Messages* buffer
> (view-echo-area-messages)
>
> ;; trigger a logical error to display the *Backtrace* buffer
> (> vim emacs)
>
> ;; trigger a quit-restore-window by calling kill-buffer in a   dedicated window
> (kill-buffer (get-buffer "*Backtrace*"))
> ;; the dedicated property has been cleaned from the window,
> ;; yet *Messages* is displayed in place of this window !
> (kill-buffer (get-buffer "*Messages*"))
> ;; calling kill-buffer in a non-dedicated window,
> ;; does not trigger quit-restore-window anymore
> ;; resulting in an undesirable buffer being displayed in place.
>
>
> What is the desired behavior of a dedicated window here ?
> Must *Messages* be displayed after we killed *Backtrace* in the first
> place ?

I think so, yes.

> I am suspecting that the locale value of `kill-buffer-hook' in
> *Backtrace* is interfering with this test but I have difficulties to
> find its human readable form.

I doubt that.  It's probably due to my fix for Bug#48493.  When
*Messages* is killed, the window should have no more previous buffers to
display and we should be able to kill it.  But `switch-to-prev-buffer'
shows the "next" buffer instead.  Try to come up with a solution that
does not reintroduce Bug#48493 and deletes the window when no previous
buffer is found.

martin

Message #30 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 01:58:22 +0000

>> What is the desired behavior of a dedicated window here ?
>> Must *Messages* be displayed after we killed *Backtrace* in the 
>> first
>> place ?
>
> I think so, yes.

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.

I am testing a version of this.

> [...] When
> *Messages* is killed, the window should have no more previous 
> buffers to
> display and we should be able to kill it.  But 
> `switch-to-prev-buffer'
> shows the "next" buffer instead.  Try to come up with a solution 
> that
> does not reintroduce Bug#48493 and deletes the window when no 
> previous
> buffer is found.

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.

--

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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 08:50:10 +0200

> 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?

> 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)))

martin

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.

-- 

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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 18:28:48 +0200

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

You're right, I forgot that side windows are by default dedicated to
their buffers.

The dedicated flag in a side window serves to prevent "normal" buffer
display to "avoid" that window.  A side window may be reused for showing
another buffer only by `display-buffer-in-side-window'.  This sense of
dedication is somewhat different from the normal sense where killing the
buffer always attempts to delete its dedicated windows (and maybe their
frames too) first.

Hence it is perfectly valid to switch to the previous buffer here - any
such buffer was meant to be displayed in that side window.  It would be,
however, invalid to switch to some buffer that was never shown in that
window here.  Note in this context that we can always delete a side
window, a side window can never be alone on its frame.

> 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.

So maybe something like this might cut it:

      (if (and prev-buffer (memq (window-dedicated-p window) '(nil side)))
          ;; 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)))

Tell me whether this works with DOOM's `kill-buffer-hook'.

If you feel that it's more natural to delete the window in the case at
hand, we can consider that too.  But suppose someone uses such a side
window for something more permanent like a compile or shell buffer and
the backtrace buffer kicked in only accidentally, then deleting the side
window when killing the backtrace buffer might not be a good idea.

martin

Message #42 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: Wed, 26 May 2021 16:10:15 +0000

[Message part 1 (text/plain, inline)]

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

> The dedicated flag in a side window serves to prevent "normal" buffer
> display to "avoid" that window.  A side window may be reused for showing
> another buffer only by `display-buffer-in-side-window'.  This sense of
> dedication is somewhat different from the normal sense where killing the
> buffer always attempts to delete its dedicated windows (and maybe their
> frames too) first.
>
> Hence it is perfectly valid to switch to the previous buffer here - any
> such buffer was meant to be displayed in that side window.  It would be,
> however, invalid to switch to some buffer that was never shown in that
> window here.  Note in this context that we can always delete a side
> window, a side window can never be alone on its frame.

Yes.

> Tell me whether this works with DOOM's `kill-buffer-hook'.

I can test the changes against a version of DOOM, yes. For the draft below
it seems to be ok, but keep in mind that their library bypass these parts
window.el

> If you feel that it's more natural to delete the window in the case at
> hand, we can consider that too.

Not at all. For me it is ok with switch-to-prev-buffer, if users want to delete
the window and/or buffer explicitly, they have commands for that. In the case of
DOOM it is implemented as a workaround against some bugs, it is
explicated in :

(+popup/quit-window)
Documentation
The regular quit-window sometimes kills the popup buffer and switches to a
buffer that shouldn't be in a popup. We prevent that by remapping quit-window
to this commmand.


So here is the *draft* that pass the previous cases of this thread.
`replace-buffer-in-windows' take care of killing buffers.
I restore the dedication of side-window because :
1. it seems to me it is the right think to do, and it prevents 2.
2. I lost the trace when we kill a buffer and no previous-buffer is found
but  still an undesirable buffer replace the current,
is it in the C part ? I can't inspect C...

[0001-Better-handling-of-side-windows.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

I will pass the rest of they day to look at ERT to see if I can learn
how to write reusable tests and see if this discussion needs to be reflected
in the documentation.

--

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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: Thu, 27 May 2021 09:47:20 +0200

> I can test the changes against a version of DOOM, yes. For the draft below
> it seems to be ok, but keep in mind that their library bypass these parts
> window.el

You already told me so.

>> If you feel that it's more natural to delete the window in the case at
>> hand, we can consider that too.
>
> Not at all. For me it is ok with switch-to-prev-buffer, if users want to delete
> the window and/or buffer explicitly, they have commands for that. In the case of
> DOOM it is implemented as a workaround against some bugs, it is
> explicated in :
>
> (+popup/quit-window)
> Documentation
> The regular quit-window sometimes kills the popup buffer and switches to a
> buffer that shouldn't be in a popup. We prevent that by remapping quit-window
> to this commmand.

Maybe this is precisely the behavior you're trying to fix and their fix
won't then be needed any more.

> So here is the *draft* that pass the previous cases of this thread.
> `replace-buffer-in-windows' take care of killing buffers.
> I restore the dedication of side-window because :
> 1. it seems to me it is the right think to do, and it prevents 2.

This is quite a weakness of the present mechanism and I think you got
it right.  To summarize your approach:

- When we have to replace a buffer in a side window, that window's
  dedicated status is 'side', and some other buffer is found that was
  shown there before (it's on the list of that window's _previous_
  buffers) we show that other buffer in the window and make sure to
  restore the window's dedicated status to 'side'.

- Otherwise delete the window.  Deleting the window is always possible
  and we have to make sure one thing - never show in a side window a
  buffer that has not been shown before in that window.  This rule
  should take care of the DOOM workaround.

And users who override the behavior sketched here by setting the side
window's dedicated status to t should have the window deleted (since
that is always possible).

Have I got it right?

> 2. I lost the trace when we kill a buffer and no previous-buffer is found
> but  still an undesirable buffer replace the current,
> is it in the C part ? I can't inspect C...

IIUC you mean the one in `kill-buffer' in buffer.c.  `kill-buffer' first
calls

  replace_buffer_in_windows (buffer);

which simply calls the Lisp function `replace-buffer-in-windows' for
buffer (the buffer to kill) and later on does

  replace_buffer_in_windows_safely (buffer);

That last call will show another buffer in a window if and only if
`replace-buffer-in-windows' failed to do its work which is an unusual
case - one that should _not_ have happened.  But we must, in C, simply
make sure that such a failure gets caught since showing a dead buffer in
a live window can crash Emacs.  So if replace_buffer_in_windows_safely
shows another buffer, then something in `replace-buffer-in-windows' was
already broken before and we need not bother to clean up things.

> I will pass the rest of they day to look at ERT to see if I can learn
> how to write reusable tests and see if this discussion needs to be reflected
> in the documentation.

We have to document it in the Elisp manual.

martin

Message #48 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, 08 Jun 2021 01:23:11 +0200

[Message part 1 (text/plain, inline)]

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

> This is quite a weakness of the present mechanism and I think 
> you got
> it right.  To summarize your approach:
>
> - When we have to replace a buffer in a side window, that 
> window's
>   dedicated status is 'side', and some other buffer is found 
>   that was
>   shown there before (it's on the list of that window's 
>   _previous_
>   buffers) we show that other buffer in the window and make sure 
>   to
>   restore the window's dedicated status to 'side'.
>
> - Otherwise delete the window.  Deleting the window is always 
> possible
>   and we have to make sure one thing - never show in a side 
>   window a
>   buffer that has not been shown before in that window.  This 
>   rule
>   should take care of the DOOM workaround.
>
> And users who override the behavior sketched here by setting the 
> side
> window's dedicated status to t should have the window deleted 
> (since
> that is always possible).
>
> Have I got it right?

Yes.
Maybe it is a step toward implementing the `soft' dedication that 
is mentioned in the comments.
Thanks you for the explanations.

> We have to document it in the Elisp manual.

Here another draft with the info manual changes:

From what I have tested so far, there were more functions that 
needed to preserve the side dedication. I put in my modeline a 
token for the window dedication and it was quite useful to spot 
them (maybe not the clever way but worked). I also grepped into 
window.el to see if I was missing something without more success.

There is a change in the indentation of `quit-restore-window' and 
I don't know if there is convention in such cases.

[0001-Improve-handling-of-dedicated-side-flag-when-quittin.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

--

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

From: pillule <pillule <at> riseup.net>
To: pillule <pillule <at> riseup.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 48493 <at> debbugs.gnu.org,
 Sujith Manoharan <sujith.wall <at> gmail.com>
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Tue, 08 Jun 2021 11:24:17 +0200

[Message part 1 (text/plain, inline)]

pillule <pillule <at> riseup.net> writes:

> martin rudalics <rudalics <at> gmx.at> writes:
>
>> This is quite a weakness of the present mechanism and I think 
>> you got
>> it right.  To summarize your approach:
>>
>> - When we have to replace a buffer in a side window, that 
>> window's
>>   dedicated status is 'side', and some other buffer is found 
>>   that was
>>   shown there before (it's on the list of that window's 
>>   _previous_
>>   buffers) we show that other buffer in the window and make 
>>   sure   to
>>   restore the window's dedicated status to 'side'.
>>
>> - Otherwise delete the window.  Deleting the window is always 
>> possible
>>   and we have to make sure one thing - never show in a side 
>>   window a
>>   buffer that has not been shown before in that window.  This 
>>   rule
>>   should take care of the DOOM workaround.
>>
>> And users who override the behavior sketched here by setting 
>> the side
>> window's dedicated status to t should have the window deleted 
>> (since
>> that is always possible).
>>
>> Have I got it right?
>
> Yes.
> Maybe it is a step toward implementing the `soft' dedication 
> that is mentioned in the comments.
> Thanks you for the explanations.
>
>> We have to document it in the Elisp manual.
>
> Here another draft with the info manual changes:
>
> From what I have tested so far, there were more functions that 
> needed to preserve the side
> dedication. I put in my modeline a token for the window 
> dedication and it was quite useful to spot
> them (maybe not the clever way but worked). I also grepped into 
> window.el to see if I was missing
> something without more success.
>
> There is a change in the indentation of `quit-restore-window' 
> and I don't know if there is
> convention in such cases.

Sorry I forgot a last fix on `quit-restore-window' in the last 
message please consider instead this one :
(because switch-to-prev/next-buffer must return nil in case of no 
available buffer, we can use it in conditional and simplify the 
code, also the previous version was changing the behavior of some 
windows by deleting them when it was not necessary)

[0002-Improve-handling-of-side-dedicated-flag.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

--

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: pillule <pillule <at> riseup.net>
Cc: pillule <at> riseup.net, rudalics <at> gmx.at, 48493 <at> debbugs.gnu.org,
 sujith.wall <at> gmail.com
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Tue, 08 Jun 2021 15:09:49 +0300

> From: pillule <pillule <at> riseup.net>
> Date: Tue, 08 Jun 2021 01:23:11 +0200
> Cc: pillule <pillule <at> riseup.net>, Sujith Manoharan <sujith.wall <at> gmail.com>,
>  48493 <at> debbugs.gnu.org
> 
> > We have to document it in the Elisp manual.
> 
> Here another draft with the info manual changes:

Thanks.  Once again, I leave it to Martin and others to comment on
most of the essence of the patch, and provide here only few minor
nits:

> * doc/lispref/windows.texi
>   (Buffers and Windows): mention the exception of side windows and
> add a reference.
>   (Buffer Display Action Alists): explicit that
> `display-buffer-in-side-window' is dedicating to side by default.
>   (Dedicated Windows): add the case (4) and explicit its meaning,
> add a reference.
>   (Displaying Buffers in Side Windows): move the
> switch-to-(prev|next)-buffer paragraph into a new item to emphasize
> the special meaning of dedication for side windows.

Again, this log message is not formatted according to our rules.  It
should look like this:

* doc/lispref/windows.texi (Buffers and Windows): Mention the
exception of side windows and add a reference.
(Buffer Display Action Alists): Say explicitly that
'display-buffer-in-side-window' is dedicating to side by default.
(Dedicated Windows): Add case (4) and explain its meaning, add
a reference.
(Displaying Buffers in Side Windows): Move the paragraph about
'switch-to-(prev|next)-buffer' into a new item to emphasize the
special meaning of dedication for side windows.

Note that I also fixed the wording a bit, and that our conventions for
quoting in log entries is 'like this'.

>  The replacement buffer in each window is chosen via
> -@code{switch-to-prev-buffer} (@pxref{Window History}).  Any dedicated
> -window displaying @var{buffer-or-name} is deleted if possible
> -(@pxref{Dedicated Windows}).  If such a window is the only window on its
> -frame and there are other frames on the same terminal, the frame is
> -deleted as well.  If the dedicated window is the only window on the only
> -frame on its terminal, the buffer is replaced anyway.
> +@code{switch-to-prev-buffer} (@pxref{Window History}).  With the
> +exception of side windows, any dedicated window displaying
   ^^^^^^^^^^^^^^^^^^^^^^^^^
Here' it is quite important that the reader understands what are "side
windows", otherwise he/she will not understand the exception.
However, "side window" was not yet described in the manual by this
point, and its description is not in this section.  In these cases,
always include a cross-reference to where the term is described, like
this:

  With the exception of side windows (@pxref{Side Windows}), any ...

>     In particular, @code{delete-windows-on} (@pxref{Deleting Windows})
> -handles case (2) by deleting the associated frame and case (3) by
> -showing another buffer in that frame's only window.  The function
> +handles case (2) by deleting the associated frame and case (3) and (4)
                                                         ^^^^
"cases", plural.

> +@item dedicated
> +The dedicated flag is not reserved to this function but have a
                                                      ^    ^^^^
A comma is missing before "but".  Also, please use "has" instead of
"have".

> +slightly different meaning for side windows.  They receive it upon
> +creation with the value @code{side}; it serves to prevent
> +@code{display-buffer} to uses these windows with others action
                         ^^^^^^^
"to use"

> +functions, and it persists across invocations of @code{quit-window},
> +@code{kill-buffer}, @code{previous-buffer} and @code{next-buffer}
> +(@pxref{note Window History}).  In particular, these commands will
           ^^^^^^^^^^^^^^^^^^^
No need for "note" here.

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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: Wed, 9 Jun 2021 10:33:37 +0200

Thanks for the patches.  Please follow ELi's suggestions first, I'll
then comment on the manual changes.

-	(current (eq (window-buffer window) (current-buffer))))
+	(current (eq (window-buffer window) (current-buffer)))
+        (dedicated (window-dedicated-p window)))
     (set-window-buffer window buffer)
+    ;; restore the dedicated side flag
+    (when (eq dedicated 'side)
+      (set-window-dedicated-p window 'side))

Here you could use the 'dedicated-side' solution you used below in
`replace-buffer-in-windows'.

+    (or ;; first try to delete dedicated windows that are not side windows
+     (and dedicated (not (eq dedicated 'side))
+          (window--delete window 'dedicated (eq bury-or-kill 'kill)))
+     (cond
+       ((and (not prev-buffer)
+             (eq (nth 1 quit-restore) 'tab)
+             (eq (nth 3 quit-restore) buffer))
+        (tab-bar-close-tab)
+        ;; If the previously selected window is still alive, select it.
+        (when (window-live-p (nth 2 quit-restore))
+          (select-window (nth 2 quit-restore))))

What's wrong with putting the first disjunct into the conditional as in
the below?  In general, always try to avoid larger indentation changes -
they can make forensics cumbersome while bisecting.

     (cond
      ;; First try to delete dedicated windows that are not side windows
      ((and dedicated (not (eq dedicated 'side))
            (window--delete window 'dedicated (eq bury-or-kill 'kill))))
      ((and (not prev-buffer)
             (eq (nth 1 quit-restore) 'tab)
             (eq (nth 3 quit-restore) buffer))

BTW, how's your paperwork process proceeding?

martin

Message #60 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: Wed, 09 Jun 2021 14:34:54 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: pillule <pillule <at> riseup.net>
>> Date: Tue, 08 Jun 2021 01:23:11 +0200
>> Cc: pillule <pillule <at> riseup.net>, Sujith Manoharan 
>> <sujith.wall <at> gmail.com>,
>>  48493 <at> debbugs.gnu.org
>>
>> > We have to document it in the Elisp manual.
>>
>> Here another draft with the info manual changes:
>
> Thanks.  Once again, I leave it to Martin and others to comment 
> on
> most of the essence of the patch, and provide here only few 
> minor
> nits:
>
>> * doc/lispref/windows.texi
>>   (Buffers and Windows): mention the exception of side windows 
>>   and
>> add a reference.
>>   (Buffer Display Action Alists): explicit that
>> `display-buffer-in-side-window' is dedicating to side by 
>> default.
>>   (Dedicated Windows): add the case (4) and explicit its 
>>   meaning,
>> add a reference.
>>   (Displaying Buffers in Side Windows): move the
>> switch-to-(prev|next)-buffer paragraph into a new item to 
>> emphasize
>> the special meaning of dedication for side windows.
>
> Again, this log message is not formatted according to our rules. 
> It
> should look like this:
>
> * doc/lispref/windows.texi (Buffers and Windows): Mention the
> exception of side windows and add a reference.
> (Buffer Display Action Alists): Say explicitly that
> 'display-buffer-in-side-window' is dedicating to side by 
> default.
> (Dedicated Windows): Add case (4) and explain its meaning, add
> a reference.
> (Displaying Buffers in Side Windows): Move the paragraph about
> 'switch-to-(prev|next)-buffer' into a new item to emphasize the
> special meaning of dedication for side windows.
>
> Note that I also fixed the wording a bit, and that our 
> conventions for
> quoting in log entries is 'like this'.
>
>>  The replacement buffer in each window is chosen via
>> -@code{switch-to-prev-buffer} (@pxref{Window History}).  Any 
>> dedicated
>> -window displaying @var{buffer-or-name} is deleted if possible
>> -(@pxref{Dedicated Windows}).  If such a window is the only 
>> window on its
>> -frame and there are other frames on the same terminal, the 
>> frame is
>> -deleted as well.  If the dedicated window is the only window 
>> on the only
>> -frame on its terminal, the buffer is replaced anyway.
>> +@code{switch-to-prev-buffer} (@pxref{Window History}).  With 
>> the
>> +exception of side windows, any dedicated window displaying
>    ^^^^^^^^^^^^^^^^^^^^^^^^^
> Here' it is quite important that the reader understands what are 
> "side
> windows", otherwise he/she will not understand the exception.
> However, "side window" was not yet described in the manual by 
> this
> point, and its description is not in this section.  In these 
> cases,
> always include a cross-reference to where the term is described, 
> like
> this:
>
>   With the exception of side windows (@pxref{Side Windows}), any 
>   ...
>
>>     In particular, @code{delete-windows-on} (@pxref{Deleting 
>>     Windows})
>> -handles case (2) by deleting the associated frame and case (3) 
>> by
>> -showing another buffer in that frame's only window.  The 
>> function
>> +handles case (2) by deleting the associated frame and case (3) 
>> and (4)
>                                                          ^^^^
> "cases", plural.
>

Here note that I suppressed the comment

@c FIXME: Does replace-buffer-in-windows _delete_ a window in case 
(1)?

Because yes, it is the case.

>> +@item dedicated
>> +The dedicated flag is not reserved to this function but have a
>                                                       ^    ^^^^
> A comma is missing before "but".  Also, please use "has" instead 
> of
> "have".
>
>> +slightly different meaning for side windows.  They receive it 
>> upon
>> +creation with the value @code{side}; it serves to prevent
>> +@code{display-buffer} to uses these windows with others action
>                          ^^^^^^^
> "to use"
>
>> +functions, and it persists across invocations of 
>> @code{quit-window},
>> +@code{kill-buffer}, @code{previous-buffer} and 
>> @code{next-buffer}
>> +(@pxref{note Window History}).  In particular, these commands 
>> will
>            ^^^^^^^^^^^^^^^^^^^
> No need for "note" here.

Thanks.  Got them.

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

> Thanks for the patches.  Please follow ELi's suggestions first, 
> I'll
> then comment on the manual changes.
>
> -	(current (eq (window-buffer window) (current-buffer))))
> +	(current (eq (window-buffer window) (current-buffer)))
> +        (dedicated (window-dedicated-p window)))
>      (set-window-buffer window buffer)
> +    ;; restore the dedicated side flag
> +    (when (eq dedicated 'side)
> +      (set-window-dedicated-p window 'side))
>
> Here you could use the 'dedicated-side' solution you used below 
> in
> `replace-buffer-in-windows'.

ok

> +    (or ;; first try to delete dedicated windows that are not 
> side windows
> +     (and dedicated (not (eq dedicated 'side))
> +          (window--delete window 'dedicated (eq bury-or-kill 
> 'kill)))
> +     (cond
> +       ((and (not prev-buffer)
> +             (eq (nth 1 quit-restore) 'tab)
> +             (eq (nth 3 quit-restore) buffer))
> +        (tab-bar-close-tab)
> +        ;; If the previously selected window is still alive, 
> select it.
> +        (when (window-live-p (nth 2 quit-restore))
> +          (select-window (nth 2 quit-restore))))
>
> What's wrong with putting the first disjunct into the 
> conditional as in
> the below?  In general, always try to avoid larger indentation 
> changes -
> they can make forensics cumbersome while bisecting.
>
>      (cond
>       ;; First try to delete dedicated windows that are not side 
>       windows
>       ((and dedicated (not (eq dedicated 'side))
>             (window--delete window 'dedicated (eq bury-or-kill 
>             'kill))))
>       ((and (not prev-buffer)
>              (eq (nth 1 quit-restore) 'tab)
>              (eq (nth 3 quit-restore) buffer))

The difference is a window dedicated with flag t may not be 
deletable, and in this case, we want it
to pass through the others conditionals branch of 
quit-restore-window, so it can try to use the
'quit-restore parameter, close the tab or to fallback in t, etc.
Explaining it makes me thing I could use 'window-deletable-p' in 
its conditional and ...
I guess, problem solved

In this revision I also restored the use of (select-window (nth 2 
quit-restore)) on the branch t.

> BTW, how's your paperwork process proceeding?

I am currently exchanging with the clerk to complete it.

[0003-Improve-handling-of-side-dedicated-flag.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

--

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

From: pillule <pillule <at> riseup.net>
To: pillule <pillule <at> riseup.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 48493 <at> debbugs.gnu.org,
 Sujith Manoharan <sujith.wall <at> gmail.com>
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Wed, 09 Jun 2021 15:00:38 +0200

>> What's wrong with putting the first disjunct into the 
>> conditional as in
>> the below?  In general, always try to avoid larger indentation 
>> changes -
>> they can make forensics cumbersome while bisecting.
>>
>>      (cond
>>       ;; First try to delete dedicated windows that are not 
>>       side       windows
>>       ((and dedicated (not (eq dedicated 'side))
>>             (window--delete window 'dedicated (eq bury-or-kill 
>>             'kill))))
>>       ((and (not prev-buffer)
>>              (eq (nth 1 quit-restore) 'tab)
>>              (eq (nth 3 quit-restore) buffer))
>
> The difference is a window dedicated with flag t may not be 
> deletable, and in this case, we want it
> to pass through the others conditionals branch of 
> quit-restore-window, so it can try to use the
> 'quit-restore parameter, close the tab or to fallback in t, etc.
> Explaining it makes me thing I could use 'window-deletable-p' in 
> its conditional and ...
> I guess, problem solved
>

I read it again and think you were right,
when  (window--delete window 'dedicated (eq bury-or-kill 'kill))
is part of the conditional, it indeed already fail if the window 
is not deletable ;

I will correct that in the next revision.

--

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

From: pillule <pillule <at> riseup.net>
To: pillule <pillule <at> riseup.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 48493 <at> debbugs.gnu.org,
 Sujith Manoharan <sujith.wall <at> gmail.com>
Subject: Re: bug#48493: 28.0.50; quit-window doesn't work
Date: Wed, 09 Jun 2021 15:36:44 +0200

[Message part 1 (text/plain, inline)]

pillule <pillule <at> riseup.net> writes:

>>> What's wrong with putting the first disjunct into the 
>>> conditional as in
>>> the below?  In general, always try to avoid larger indentation 
>>> changes -
>>> they can make forensics cumbersome while bisecting.
>>>
>>>      (cond
>>>       ;; First try to delete dedicated windows that are not 
>>>       side       windows
>>>       ((and dedicated (not (eq dedicated 'side))
>>>             (window--delete window 'dedicated (eq bury-or-kill 
>>>             'kill))))
>>>       ((and (not prev-buffer)
>>>              (eq (nth 1 quit-restore) 'tab)
>>>              (eq (nth 3 quit-restore) buffer))
>>
>> The difference is a window dedicated with flag t may not be 
>> deletable, and in this case, we want
>> it
>> to pass through the others conditionals branch of 
>> quit-restore-window, so it can try to use the
>> 'quit-restore parameter, close the tab or to fallback in t, 
>> etc.
>> Explaining it makes me thing I could use 'window-deletable-p' 
>> in its conditional and ...
>> I guess, problem solved
>>
>
> I read it again and think you were right,
> when  (window--delete window 'dedicated (eq bury-or-kill 'kill))
> is part of the conditional, it indeed already fail if the window 
> is not deletable ;
>
> I will correct that in the next revision.

hm. here again minors corrections. sorry for the noise.

[0004-Improve-handling-of-side-dedicated-flag.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

--

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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: Sun, 13 Jun 2021 10:49:45 +0200

> hm. here again minors corrections. sorry for the noise.

OK.  Please inform me as soon as your paperwork is complete.

Thanks, martin

Message #72 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: Sun, 13 Jun 2021 11:28:32 +0200

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

>> hm. here again minors corrections. sorry for the noise.
>
> OK.  Please inform me as soon as your paperwork is complete.
>
> Thanks, martin

I get the papers, get the papers !

--

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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: Sun, 13 Jun 2021 16:52:01 +0200

> I get the papers, get the papers !

Congratulations!

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: pillule <pillule <at> riseup.net>
Cc: 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: Mon, 14 Jun 2021 10:28:45 +0200

> here again minors corrections. sorry for the noise.

I pushed that change now with some minor modifications.  Please have a
look.

Thanks, martin

Message #81 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, 15 Jun 2021 18:53:33 +0200

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

>> here again minors corrections. sorry for the noise.
>
> I pushed that change now with some minor modifications.  Please have a
> look.
>
> Thanks, martin

Thanks :)

--

Previous Next

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