* bug#11039: 24.0.94; Window incorrectly getting selected
@ 2012-03-18 13:52 Chong Yidong
2012-03-18 18:48 ` martin rudalics
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2012-03-18 13:52 UTC (permalink / raw)
To: 11039
With latest trunk,
1. emacs -Q --maximized
2. C-x 3
3. C-x o
4. C-x 2
5. C-x o C-x o
This puts a full-height window on the left, which is selected; and two
half-height windows on the right.
6. C-h k m
The topmost half-height window on the right now shows the *Help* buffer.
But that window is selected---this is the bug. The help commands should
not switch windows.
The bug does not occur if there are just two side-by-side windows.
In GNU Emacs 24.0.94.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0)
of 2012-03-18 on ulysses
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Configured using:
`configure '--with-x-toolkit=gtk3' 'CFLAGS=-g''
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11039: 24.0.94; Window incorrectly getting selected
2012-03-18 13:52 bug#11039: 24.0.94; Window incorrectly getting selected Chong Yidong
@ 2012-03-18 18:48 ` martin rudalics
2012-03-19 6:05 ` Chong Yidong
0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2012-03-18 18:48 UTC (permalink / raw)
To: Chong Yidong; +Cc: 11039
> With latest trunk,
>
> 1. emacs -Q --maximized
> 2. C-x 3
> 3. C-x o
> 4. C-x 2
> 5. C-x o C-x o
>
> This puts a full-height window on the left, which is selected; and two
> half-height windows on the right.
>
> 6. C-h k m
>
> The topmost half-height window on the right now shows the *Help* buffer.
> But that window is selected---this is the bug. The help commands should
> not switch windows.
>
> The bug does not occur if there are just two side-by-side windows.
This is the default behavior since 23.1. If you don't like it, you can
customize `help-window-select' to nil.
martin
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11039: 24.0.94; Window incorrectly getting selected
2012-03-18 18:48 ` martin rudalics
@ 2012-03-19 6:05 ` Chong Yidong
2012-03-19 7:56 ` martin rudalics
0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2012-03-19 6:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 11039
martin rudalics <rudalics@gmx.at> writes:
> This is the default behavior since 23.1. If you don't like it, you
> can customize `help-window-select' to nil.
Ah, I didn't remember the existence of this variable. What's the
rationale? I went back and searched emacs-devel, and couldn't find any
relevant discussion. The behavior seems rather counter-intuitive.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11039: 24.0.94; Window incorrectly getting selected
2012-03-19 6:05 ` Chong Yidong
@ 2012-03-19 7:56 ` martin rudalics
2012-03-20 9:05 ` Chong Yidong
0 siblings, 1 reply; 7+ messages in thread
From: martin rudalics @ 2012-03-19 7:56 UTC (permalink / raw)
To: Chong Yidong; +Cc: 11039
> Ah, I didn't remember the existence of this variable. What's the
> rationale? I went back and searched emacs-devel, and couldn't find any
> relevant discussion. The behavior seems rather counter-intuitive.
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.
martin
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11039: 24.0.94; Window incorrectly getting selected
2012-03-19 7:56 ` martin rudalics
@ 2012-03-20 9:05 ` Chong Yidong
2012-03-20 10:57 ` martin rudalics
2012-03-20 12:57 ` Juanma Barranquero
0 siblings, 2 replies; 7+ messages in thread
From: Chong Yidong @ 2012-03-20 9:05 UTC (permalink / raw)
To: martin rudalics; +Cc: 11039
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11039: 24.0.94; Window incorrectly getting selected
2012-03-20 9:05 ` Chong Yidong
@ 2012-03-20 10:57 ` martin rudalics
2012-03-20 12:57 ` Juanma Barranquero
1 sibling, 0 replies; 7+ messages in thread
From: martin rudalics @ 2012-03-20 10:57 UTC (permalink / raw)
To: Chong Yidong; +Cc: 11039
> 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.
At the time I wrote this there were many complaints that quitting help
is messy and I tried to address that. So if you really want to change
something, you might consider a solution where we don't select a help
window when it got reused. Aynthing else will throw off people who get
help in a new window and want to get rid of that window easily.
martin
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#11039: 24.0.94; Window incorrectly getting selected
2012-03-20 9:05 ` Chong Yidong
2012-03-20 10:57 ` martin rudalics
@ 2012-03-20 12:57 ` Juanma Barranquero
1 sibling, 0 replies; 7+ messages in thread
From: Juanma Barranquero @ 2012-03-20 12:57 UTC (permalink / raw)
To: Chong Yidong; +Cc: 11039
On Tue, Mar 20, 2012 at 10:05, Chong Yidong <cyd@gnu.org> wrote:
> 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.
OTOH, dismissing the help window automatically is what I do like 95%
of the time, because I mostly want to remember some detail I've
forgotten. In fact, until Martin's new window stuff I used ehelp to
make it easier, and resorted to exiting the electric loop in the few
cases that I really wanted to keep the help window around. Now I have
an entry in `display-buffer-alist' that calls an action function of my
own to autoselect all \*Help(.*) windows, regardless of the setting of
`help-window-select' (and I'm quite glad of getting rid of ehelp).
Which is to say, the "display help / take a look / dismiss at once"
pattern isn't unheard of.
Juanma
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-03-20 12:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-18 13:52 bug#11039: 24.0.94; Window incorrectly getting selected Chong Yidong
2012-03-18 18:48 ` martin rudalics
2012-03-19 6:05 ` Chong Yidong
2012-03-19 7:56 ` martin rudalics
2012-03-20 9:05 ` Chong Yidong
2012-03-20 10:57 ` martin rudalics
2012-03-20 12:57 ` Juanma Barranquero
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).