[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11039: 24.0.94; Window incorrectly getting selected
From: |
Chong Yidong |
Subject: |
bug#11039: 24.0.94; Window incorrectly getting selected |
Date: |
Tue, 20 Mar 2012 17:05:11 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) |
martin rudalics <rudalics@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.