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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11039 in the body.
You can then email your comments to 11039 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Chong Yidong <cyd <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94; Window incorrectly getting selected
Date: Sun, 18 Mar 2012 21:52:34 +0800

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''

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

From: martin rudalics <rudalics <at> gmx.at>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 11039 <at> debbugs.gnu.org
Subject: Re: bug#11039: 24.0.94; Window incorrectly getting selected
Date: Sun, 18 Mar 2012 19:48:32 +0100

> 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

Message #11 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: Mon, 19 Mar 2012 14:05:25 +0800

martin rudalics <rudalics <at> 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.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Chong Yidong <cyd <at> gnu.org>
Cc: 11039 <at> debbugs.gnu.org
Subject: Re: bug#11039: 24.0.94; Window incorrectly getting selected
Date: Mon, 19 Mar 2012 08:56:55 +0100

> 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

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.

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

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

> 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

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 11039 <at> debbugs.gnu.org
Subject: Re: bug#11039: 24.0.94; Window incorrectly getting selected
Date: Tue, 20 Mar 2012 13:57:23 +0100

On Tue, Mar 20, 2012 at 10:05, Chong Yidong <cyd <at> 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

Previous Next

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