GNU bug report logs - #11039
24.0.94; Window incorrectly getting selected

Previous Next

Full log

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

From: Chong Yidong <cyd <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 11039 <at> debbugs.gnu.org
Subject: Re: bug#11039: 24.0.94; Window incorrectly getting selected
Date: Tue, 20 Mar 2012 17:05:11 +0800

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

> When the help window is one out of three windows on a frame and you do
> _not_ select it, it's quite difficult to restore the state of the frame
> before showing help.  You would have to (1) manually switch to the help
> window, (2) type "q" in it, and maybe (3) switch back to the previously
> selected window.  If, however, you _do_ select the help window, you can
> simply type "q" in it and get back the old state of affairs.
>
> The more problematic case occurs rather when there are only two windows
> and help reuses the other window.  In this case the default value of
> `help-window-select' means you have to manually switch to that other
> window and type "q" there.

IMO, this is a very inconsistent interface.  Help windows ought to stick
closely to the default `display-buffer' behavior.  I don't see why they
should be treated so differently from other "display XYZ in another
window" commands.  In fact, the default `other' value seems like the
worst of all worlds.

You seem to be assuming that the user wants to dismiss the help window
immediately, but I don't think that that's a justified assumption.  When
writing Emacs Lisp code, for instance, I like to leave one window open
for the *Help* buffer, and this behavior keeps switching me out of the
code buffer.

Previous Next

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