bug#1322: dedicated *Help* and M-x help-for-help

bug#1322: dedicated *Help* and M-x help-for-help

[David Reitter]

`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@jm3.net>
> Date: 8 November 2008 00:33:02 EST
> To: aquamacs-bugs@aquamacs.org
> Cc: John Manoogian III <jm3@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''

bug#1322: dedicated *Help* and M-x help-for-help

[martin rudalics]

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

bug#1322: dedicated *Help* and M-x help-for-help

[Geoff Gole]

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.

bug#1322: dedicated *Help* and M-x help-for-help

[Drew Adams]

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

bug#1322: dedicated *Help* and M-x help-for-help

[martin rudalics]

 > 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

bug#1322: dedicated *Help* and M-x help-for-help

[Geoff Gole]

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

bug#1322: dedicated *Help* and M-x help-for-help

[martin rudalics]

 > 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