[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quit-window new behavior with frames

From: Thierry Volpiatto
Subject: Re: quit-window new behavior with frames
Date: Thu, 22 Sep 2011 08:06:53 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

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 

--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 
  switch-to-prev-buffer(#<window 114 on *Help*> bury-or-kill)
  view-mode-exit(nil nil)
  (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)))
  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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]