Re: quit-window new behavior with frames

[Thierry Volpiatto]

Hi Martin,

martin rudalics <address@hidden> 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