GNU bug report logs -
#1322
dedicated *Help* and M-x help-for-help
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 1322 in the body.
You can then email your comments to 1322 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
David Reitter <david.reitter <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
`help-on-help' cannot deal with dedicated windows.
To reproduce:
(setq special-display-buffer-names '("*Help*"))
(help-on-help)
This will open a new frame with the *Help* buffer. However, as soon
as the user presses one of the keys (e.g., `a`), the frame is
iconified, which is unexpected and not what you get when the window is
not dedicated.
Credit for the original bug report is due to Aquamacs Emacs user John
Manoogian III.
In GNU Emacs 23.0.60.34 (i386-apple-darwin9.4.0, *Step 9.0)
of 2008-08-21 on scarlett [excuse the old version - either way,
help.el hasn't been changed since the summer]
Windowing system distributor `Apple', version 49.46.48
configured using `configure '--with-ns' '--without-x' '--with-app''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<down-mouse-1> <mouse-1> C-x b <return> ( s e t q m
SPC <backspace> <backspace> SPC s p e c i a l - d i
s p l a y - b u f f e r - a b <backspace> <backspace>
n a m e s SPC ' ( ( <backspace> " * H <backspace> <backspace>
SPC * H e l p SPC * <backspace> <backspace> * SPC "
) ) C-x C-e <return> <return> M-x <up> h e l p - o
n - h <tab> <return> e <tab> <return> <backspace> <backspace>
<backspace> <backspace> <tab> <backspace> f <tab> <return>
q <up> <left> <left> <left> <left> <backspace> <left>
<left> <left> <left> <left> <left> <backspace> <down>
C-x C-e <escape> x <up> <return> a <switch-frame> <switch-frame>
C-g <switch-frame> <down-mouse-1> <mouse-movement>
<mouse-movement> <mouse-movement> <drag-mouse-1> s-c
<down-mouse-1> <mouse-movement> <mouse-movement> <drag-mouse-1>
<tool-bar> <cut> <help-echo> <menu-bar> <help-menu>
<send-emacs-bug-report> <help-echo> <switch-frame>
<help-echo> <menu-bar> <help-menu> <send-emacs-bug-report>
<switch-frame> h e l p <return> s-w <menu-bar> <help-menu>
<send-emacs-bug-report>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Unable to load color "darkblue"
(" *Help* ")
goto-history-element: Beginning of history; no preceding item
("*Help*")
Quit
byte-code: Command attempted to use minibuffer while in minibuffer
Buffer is read-only: #<buffer *Help*> [4 times]
help-follow: No cross-reference here
Begin forwarded message:
> From: John Manoogian III <jm3 <at> jm3.net>
> Date: 8 November 2008 00:33:02 EST
> To: aquamacs-bugs <at> aquamacs.org
> Cc: John Manoogian III <jm3 <at> jm3.net>
> Subject: [Aquamacs-bugs] help-for-help buffer minimizes and ignores
> key input
>
> repro steps after following all the steps in http://aquamacs.org/
> reporting-bugs.shtml:
>
> 1. M-x help-for-help
> 2. (help buffer appears in new os x window with menu options
> a,b,c,C,d,e,f,F,h, etc.)
> 3. type any of the menu keys presented
>
> expected behavior: chosen menu activates
>
> actual behavior: window minimizes to the OS X dock, then, sometimes,
> it unminimizes itself again immediately. chosen menu does not activate
>
>
>
> In GNU Emacs 22.3.2 (i386-apple-darwin9.5.0, Carbon Version 1.6.0)
> of 2008-11-07 on plume.sr.unh.edu - Aquamacs Distribution 1.6CVS
> Windowing system distributor `Apple Inc.', version 10.4.11
> configured using `configure '--without-x' '--prefix=/usr/local''
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #10 received at 1322 <at> emacsbugs.donarmstrong.com (full text, mbox):
> `help-on-help' cannot deal with dedicated windows.
> To reproduce:
>
> (setq special-display-buffer-names '("*Help*"))
> (help-on-help)
>
> This will open a new frame with the *Help* buffer. However, as soon as
> the user presses one of the keys (e.g., `a`), the frame is iconified,
> which is unexpected and not what you get when the window is not dedicated.
This is a known problem, I shortly mentioned in
http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-10/msg00029.html
Unfortunately, `help-on-help' is broken in a couple of other respects as
well. I'm working on a comprehensive solution.
martin
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Geoff Gole" <geoffgole <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #15 received at 1322 <at> emacsbugs.donarmstrong.com (full text, mbox):
Would it be ok to just work around this by giving the
help-for-help buffer a title that is not "*Help*"? Most uses of
special-display-buffer-names aren't going to cause this problem.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Drew Adams" <drew.adams <at> oracle.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #20 received at 1322 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Would it be ok to just work around this by giving the
> help-for-help buffer a title that is not "*Help*"? Most uses of
> special-display-buffer-names aren't going to cause this problem.
Please do not do that. There is likely code, at least third-party code, that
expects *Help* to be the name - as it has always been.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #25 received at 1322 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Would it be ok to just work around this by giving the
> help-for-help buffer a title that is not "*Help*"? Most uses of
> special-display-buffer-names aren't going to cause this problem.
`help-for-help' pops up the *Help* buffer in a separate frame. Typing a
character now may cause its window display something else. Thereafter,
`help-for-help', recalling that it popped up a frame and wrongly
assuming that the user has finished viewing its buffer, decides to
iconify the frame.
So giving the `help-for-help' buffer another name ("title") should
indeed fix this and I initially thought to go that way. But, on the
other hand, we usually _want_ to reuse that frame for displaying other
help instead of having to deal with two separate help-related frames.
An easy solution is to use an extra variable, set by `help-for-help' and
reset by `with-help-window', to control iconification. But I never had
the time to check whether all functions run by `help-for-help' also run
`with-help-window'.
martin
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Geoff Gole" <geoffgole <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #30 received at 1322 <at> emacsbugs.donarmstrong.com (full text, mbox):
> An easy solution is to use an extra variable, set by `help-for-help' and
> reset by `with-help-window', to control iconification. But I never had
> the time to check whether all functions run by `help-for-help' also run
> `with-help-window'.
I'm not sure this will be sufficient. Remember that help-for-help
has entries that bring up info, NEWS, etc. Now if *Help*
is the only thing in special-display-buffer-names and
help-for-help is in it's own frame, accessing these help
functions through help-for-help is going to spawn another frame.
To see this:
emacs -Q
M-: (setq special-display-buffer-names '("*Help*"))
f1 f1 C-a
Return to first frame
f1 f1 C-n
Now there's four frames open! Surely this is not the intended
behaviour of help-for-help, even after fixing the iconification
issue.
One way to work around that is to restrict help-for-help to the
original frame in some way. If that is not acceptable then
shouldn't we at least make sure that the user's commands are
taking effect in the correct frame? It doesn't seem right that a
help command will display differently when you run it through
help-for-help.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1322
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
martin rudalics <rudalics <at> gmx.at>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #35 received at 1322 <at> emacsbugs.donarmstrong.com (full text, mbox):
> I'm not sure this will be sufficient. Remember that help-for-help
> has entries that bring up info, NEWS, etc. Now if *Help*
> is the only thing in special-display-buffer-names and
> help-for-help is in it's own frame, accessing these help
> functions through help-for-help is going to spawn another frame.
>
> To see this:
>
> emacs -Q
> M-: (setq special-display-buffer-names '("*Help*"))
> f1 f1 C-a
> Return to first frame
> f1 f1 C-n
>
> Now there's four frames open!
Yes.
> Surely this is not the intended
> behaviour of help-for-help, even after fixing the iconification
> issue.
It is. `special-display-popup-frame', for whatever reason, has
(set-window-dedicated-p (frame-selected-window frame) t)
so C-a and C-n are not allowed to use the help window because they do
not put their information into *Help*.
> One way to work around that is to restrict help-for-help to the
> original frame in some way. If that is not acceptable then
> shouldn't we at least make sure that the user's commands are
> taking effect in the correct frame? It doesn't seem right that a
> help command will display differently when you run it through
> help-for-help.
We'd have to write our own `special-display-function' for that.
martin
Reply sent to
martin rudalics <rudalics <at> gmx.at>
:
You have taken responsibility.
Full text and
rfc822 format available.
Notification sent to
David Reitter <david.reitter <at> gmail.com>
:
bug acknowledged by developer.
Full text and
rfc822 format available.
Message #40 received at 1322-done <at> emacsbugs.donarmstrong.com (full text, mbox):
> `help-on-help' cannot deal with dedicated windows.
> To reproduce:
>
> (setq special-display-buffer-names '("*Help*"))
> (help-on-help)
>
> This will open a new frame with the *Help* buffer. However, as soon as
> the user presses one of the keys (e.g., `a`), the frame is iconified,
> which is unexpected and not what you get when the window is not dedicated.
Fixed as
2008-11-17 Martin Rudalics <rudalics <at> gmx.at>
* help-macro.el
(make-help-screen): Don't iconify selected frame. (Bug#1322)
Thanks for the report, martin.
bug archived.
Request was from
Debbugs Internal Request <don <at> donarmstrong.com>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Mon, 15 Dec 2008 15:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 years and 268 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.