quit-window new behavior with frames

quit-window new behavior with frames

[Thierry Volpiatto]

Hi,
i use dedicated frames for help and compile buffers, set with
`special-display-buffer-names'.

Now when these buffers are displayed in their own frame, "q" has no
more effect.

In emacs23 and recently in 24 too, frame was deleted as expected.
 
To reproduce, use this:

--8<---------------cut here---------------start------------->8---
(setq special-display-buffer-names `((,(help-buffer)
                                     (minibuffer . nil)
                                     (width . 80)
                                     (height . 24)
                                     (left-fringe . 0)
                                     (border-width . 0)
                                     (menu-bar-lines . 0)
                                     (tool-bar-lines . 0)
                                     (unsplittable . t)
                                     (top . 24)
                                     (left . 450)
                                     (background-color . "LightSteelBlue")
                                     (foreground-color . "black")
                                     (alpha . nil)
                                     (fullscreen . nil))
                                     ("*Compile-Log*"
                                     (minibuffer . nil)
                                     (width . 85)
                                     (height . 24)
                                     (left-fringe . 0)
                                     (border-width . 0)
                                     (menu-bar-lines . 0)
                                     (tool-bar-lines . 0)
                                     (unsplittable . t)
                                     (top . 24)
                                     (left . 450)
                                     (background-color . "Palevioletred1")
                                     (foreground-color . "black")
                                     (alpha . nil)
                                     (fullscreen . nil))))
--8<---------------cut here---------------end--------------->8---

and compile some file and try to quit compile buffer with "q".

"q" should fail as well with help buffer, but not sure, because i am
using a special mode that fix this in help.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[martin rudalics]

> i use dedicated frames for help and compile buffers, set with
> `special-display-buffer-names'.
> 
> Now when these buffers are displayed in their own frame, "q" has no
> more effect.
> 
> In emacs23 and recently in 24 too, frame was deleted as expected.

I can't reproduce this at the moment but I modified quit-window
this morning.  Could you please try again?

martin

Re: quit-window new behavior with frames

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> i use dedicated frames for help and compile buffers, set with
>> `special-display-buffer-names'.
>>
>> Now when these buffers are displayed in their own frame, "q" has no
>> more effect.
>>
>> In emacs23 and recently in 24 too, frame was deleted as expected.
>
> I can't reproduce this at the moment but I modified quit-window
> this morning.  Could you please try again?
Thanks, it is working now :-)

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[Thierry Volpiatto]

Hi Martin,

martin rudalics <rudalics@gmx.at> writes:

>> i use dedicated frames for help and compile buffers, set with
>> `special-display-buffer-names'.
>>
>> Now when these buffers are displayed in their own frame, "q" has no
>> more effect.
>>
>> In emacs23 and recently in 24 too, frame was deleted as expected.
>
> I can't reproduce this at the moment but I modified quit-window
> this morning.  Could you please try again?

You have fixed this some time ago, but it come up again.

When i hit "q": (View-quit)

=>switch-to-prev-buffer: Window #<window 98 on *Help*> is dedicated to buffer *Help*

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "Window #<window 114 on *Help*> is dedicated to buffer *Help*")
  signal(error ("Window #<window 114 on *Help*> is dedicated to buffer *Help*"))
  error("Window %s is dedicated to buffer %s" #<window 114 on *Help*> #<buffer *Help*>)
  switch-to-prev-buffer(#<window 114 on *Help*> bury-or-kill)
  quit-window()
  view-mode-exit(nil nil)
  View-quit()
  (and (view-mode 1) (View-quit))
  (if (umemo-point-is-in-memo-area-p (point)) (call-interactively (global-key-binding "q")) (and (view-mode 1) (View-quit)))
  umemo-electric-quit()
  call-interactively(umemo-electric-quit nil nil)
--8<---------------cut here---------------end--------------->8---

The umemo stuf is just to switch to self-insert-command and View-quit in
different parts of help buffer, you should not care of it.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[martin rudalics]

> You have fixed this some time ago, but it come up again.
> 
> When i hit "q": (View-quit)
> 
> =>switch-to-prev-buffer: Window #<window 98 on *Help*> is dedicated to buffer *Help*

Sorry.  Please try again with revision 105871.

Thanks, martin

Re: quit-window new behavior with frames

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> You have fixed this some time ago, but it come up again.
>>
>> When i hit "q": (View-quit)
>>
>> =>switch-to-prev-buffer: Window #<window 98 on *Help*> is dedicated to buffer *Help*
>
> Sorry.  Please try again with revision 105871.
It now quit the help buffer, but don't delete the frame.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[martin rudalics]

 > It now quit the help buffer, but don't delete the frame.

Please debug `quit-window' and tell me why the conjunction below returns
nil in your case.

      ((and (not prev-buffer)
	   (eq (nth 1 quit-restore) 'frame)
	   (eq (window-deletable-p window) 'frame)
	   (eq (nth 3 quit-restore) buffer))
       ;; WINDOW's frame can be deleted.
       (delete-frame (window-frame window))

Thanks, martin

Re: quit-window new behavior with frames

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> It now quit the help buffer, but don't delete the frame.
>
> Please debug `quit-window' and tell me why the conjunction below returns
> nil in your case.

There is a previous buffer. ("*scratch*")
#+BEGIN_SRC lisp
((and (not prev-buffer) ; => Return nil here.
      (eq (nth 1 quit-restore) 'frame)
      (eq (window-deletable-p window) 'frame)
      (eq (nth 3 quit-restore) buffer))
 ;; WINDOW's frame can be deleted.
 (delete-frame (window-frame window))

#+END_SRC

This is working:

#+BEGIN_SRC lisp
((and (or (not prev-buffer)
          (window-dedicated-p))
      (eq (nth 1 quit-restore) 'frame)
      (eq (window-deletable-p window) 'frame)
      (eq (nth 3 quit-restore) buffer))
 ;; WINDOW's frame can be deleted.
 (delete-frame (window-frame window))

#+END_SRC


-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> It now quit the help buffer, but don't delete the frame.
>
> Please debug `quit-window' and tell me why the conjunction below returns
> nil in your case.
>
>      ((and (not prev-buffer)
> 	   (eq (nth 1 quit-restore) 'frame)
> 	   (eq (window-deletable-p window) 'frame)
> 	   (eq (nth 3 quit-restore) buffer))
>       ;; WINDOW's frame can be deleted.
>       (delete-frame (window-frame window))
>
> Thanks, martin

There is a previous buffer. ("*scratch*")

#+BEGIN_SRC lisp
((and (not prev-buffer) ; => Return nil here.
      (eq (nth 1 quit-restore) 'frame)
      (eq (window-deletable-p window) 'frame)
      (eq (nth 3 quit-restore) buffer))
 ;; WINDOW's frame can be deleted.
 (delete-frame (window-frame window))

#+END_SRC

And this is working:

#+BEGIN_SRC lisp
((and (or (not prev-buffer)
          (window-dedicated-p))
      (eq (nth 1 quit-restore) 'frame)
      (eq (window-deletable-p window) 'frame)
      (eq (nth 3 quit-restore) buffer))
 ;; WINDOW's frame can be deleted.
 (delete-frame (window-frame window))

#+END_SRC

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[Thierry Volpiatto]

Sorry for the duplicate mail.

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> It now quit the help buffer, but don't delete the frame.
>>
>> Please debug `quit-window' and tell me why the conjunction below returns
>> nil in your case.
>>
>>      ((and (not prev-buffer)
>> 	   (eq (nth 1 quit-restore) 'frame)
>> 	   (eq (window-deletable-p window) 'frame)
>> 	   (eq (nth 3 quit-restore) buffer))
>>       ;; WINDOW's frame can be deleted.
>>       (delete-frame (window-frame window))
>>
>> Thanks, martin
>
> There is a previous buffer. ("*scratch*")
>
> #+BEGIN_SRC lisp
> ((and (not prev-buffer) ; => Return nil here.
>       (eq (nth 1 quit-restore) 'frame)
>       (eq (window-deletable-p window) 'frame)
>       (eq (nth 3 quit-restore) buffer))
>  ;; WINDOW's frame can be deleted.
>  (delete-frame (window-frame window))
>
> #+END_SRC
>
> And this is working:
>
> #+BEGIN_SRC lisp
> ((and (or (not prev-buffer)
>           (window-dedicated-p))
>       (eq (nth 1 quit-restore) 'frame)
>       (eq (window-deletable-p window) 'frame)
>       (eq (nth 3 quit-restore) buffer))
>  ;; WINDOW's frame can be deleted.
>  (delete-frame (window-frame window))
>
> #+END_SRC

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[martin rudalics]

 > There is a previous buffer. ("*scratch*")
 > #+BEGIN_SRC lisp
 > ((and (not prev-buffer) ; => Return nil here.
 >       (eq (nth 1 quit-restore) 'frame)
 >       (eq (window-deletable-p window) 'frame)
 >       (eq (nth 3 quit-restore) buffer))
 >  ;; WINDOW's frame can be deleted.
 >  (delete-frame (window-frame window))
 >
 > #+END_SRC

I see.  `special-display-popup-frame' doesn't reset the window's
previous buffers when creating a new frame.

 > This is working:
 >
 > #+BEGIN_SRC lisp
 > ((and (or (not prev-buffer)
 >           (window-dedicated-p))
 >       (eq (nth 1 quit-restore) 'frame)
 >       (eq (window-deletable-p window) 'frame)
 >       (eq (nth 3 quit-restore) buffer))
 >  ;; WINDOW's frame can be deleted.
 >  (delete-frame (window-frame window))
 >
 > #+END_SRC

Yes.  But the initial bug was in `special-display-popup-frame'.  I want
to delete only dedicated windows/frames that never showed another buffer
during their life.  Please check again.

Thanks, martin

Re: quit-window new behavior with frames

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

> Yes.  But the initial bug was in `special-display-popup-frame'.  I want
> to delete only dedicated windows/frames that never showed another buffer
> during their life.  Please check again.
I see, this is better.
Now it works perfectly.
Thanks.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[Stefan Monnier]

> Yes.  But the initial bug was in `special-display-popup-frame'.  I want
> to delete only dedicated windows/frames that never showed another buffer
> during their life.  Please check again.

The dedicated bit is reset to nil before the window can show any other
buffer, so if dedicated is non-nil, you don't have to check
anything else.


        Stefan

Re: quit-window new behavior with frames

[martin rudalics]

 > The dedicated bit is reset to nil before the window can show any other
 > buffer, so if dedicated is non-nil, you don't have to check
 > anything else.

Not really, because the dedicated bit can be set by someone else.  Here
I only want to handle the case where the dedicated bit was set and
modified exclusively by `display-buffer' related routines.  So we have
two cases:

(1) If the dedicated bit is set by `display-buffer' routines only, it is
set at the time of creation and no other buffer is ever shown in it (at
least according to the specifications you gave earlier).  In this case,
there's no previous buffer and `quit-window' can delete the window or
frame.

(2) If the dedicated bit is set in some other way, there might be a
previous buffer and I switch to that buffer instead of deleting the
window or frame.

martin

Re: quit-window new behavior with frames

[Stefan Monnier]

>> The dedicated bit is reset to nil before the window can show any other
>> buffer, so if dedicated is non-nil, you don't have to check
>> anything else.
> Not really, because the dedicated bit can be set by someone else.

Then it's that someone else's problem: setting the bit means exactly
that we should consider that no other window was ever shown in here.

If/when you bump into a real problematic case, please report it as a bug.
I don't know of any.


        Stefan

Re: quit-window new behavior with frames

[martin rudalics]

 > Then it's that someone else's problem: setting the bit means exactly
 > that we should consider that no other window was ever shown in here.

So far this fact has not been mentioned anywhere in the documentation of
dedicated windows.  Since meanwhile the semantics of `switch-to-buffer'
wrt dedicated windows has changed too I think you should try to dedicate
a few minutes to rewriting the documentations appropriately ;-)

 > If/when you bump into a real problematic case, please report it as a bug.
 > I don't know of any.

I don't know either and I don't care.  I cared about `quit-window' DTRT
when the window was created via `special-display-popup-frame'.

martin

Re: quit-window new behavior with frames

[Stefan Monnier]

>> If/when you bump into a real problematic case, please report it as a bug.
>> I don't know of any.
> I don't know either and I don't care.

Great, then please trust me that "dedicated" implies (among a few other
things) "treats this window as if it never showed any other buffer" so
when quit-window is called in a dedicated window, you can always delete
that window (and its frame if it's the only window in the frame)
regardless of whether the buffer-list of that window includes
other things or of the quit-restore property.


        Stefan

Re: quit-window new behavior with frames

[martin rudalics]

 > Great, then please trust me that "dedicated" implies (among a few other
 > things) "treats this window as if it never showed any other buffer" so
 > when quit-window is called in a dedicated window, you can always delete
 > that window (and its frame if it's the only window in the frame)
 > regardless of whether the buffer-list of that window includes
 > other things or of the quit-restore property.

As far as our current code base is concerned I do trust you.  But I
doubt that you ever looked at what ECB does with dedicated windows.

martin

Re: quit-window new behavior with frames

[Thierry Volpiatto]

Hi Martin,

martin rudalics <rudalics@gmx.at> writes:

>> You have fixed this some time ago, but it come up again.
>>
>> When i hit "q": (View-quit)
>>
>> =>switch-to-prev-buffer: Window #<window 98 on *Help*> is dedicated to buffer *Help*
>
> Sorry.  Please try again with revision 105871.
>
> Thanks, martin
>
Same again with revision 105996.

-- 
 𝕋𝕙𝕚𝕖𝕣𝕣𝕪
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: quit-window new behavior with frames

[martin rudalics]

 >>> You have fixed this some time ago, but it come up again.
 >>>
 >>> When i hit "q": (View-quit)
 >>>
 >>> =>switch-to-prev-buffer: Window #<window 98 on *Help*> is dedicated to buffer *Help*
 >> Sorry.  Please try again with revision 105871.
 >>
 >> Thanks, martin
 >>
 > Same again with revision 105996.

What precisely happens?  The `switch-to-prev-buffer' cannot be the
culprit as shown above due to

       (set-window-dedicated-p window nil)
       (switch-to-prev-buffer window 'bury-or-kill)))

If you mean that the frame is no more deleted, you have to customize the
new option `frame-auto-hide-function'.

martin

Re: quit-window new behavior with frames

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>>> You have fixed this some time ago, but it come up again.
>>>>
>>>> When i hit "q": (View-quit)
>>>>
>>>> =>switch-to-prev-buffer: Window #<window 98 on *Help*> is dedicated to buffer *Help*
>>> Sorry.  Please try again with revision 105871.
>>>
>>> Thanks, martin
>>>
>> Same again with revision 105996.
>
> What precisely happens?  The `switch-to-prev-buffer' cannot be the
> culprit as shown above due to
>
>       (set-window-dedicated-p window nil)
>       (switch-to-prev-buffer window 'bury-or-kill)))
>
> If you mean that the frame is no more deleted, you have to customize the
> new option `frame-auto-hide-function'.
Indeed very new ;-)
Work as expected with:
(setq frame-auto-hide-function 'delete-frame)
Thanks.

-- 
 𝕋𝕙𝕚𝕖𝕣𝕣𝕪
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997