* bug#1322: dedicated *Help* and M-x help-for-help @ 2008-11-10 4:47 ` David Reitter 2008-11-10 9:46 ` martin rudalics 2008-11-17 10:30 ` bug#1322: marked as done (dedicated *Help* and M-x help-for-help) Emacs bug Tracking System 0 siblings, 2 replies; 8+ messages in thread From: David Reitter @ 2008-11-10 4:47 UTC (permalink / raw) To: emacs-pretest-bug; +Cc: jm3 `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'' ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: dedicated *Help* and M-x help-for-help 2008-11-10 4:47 ` bug#1322: dedicated *Help* and M-x help-for-help David Reitter @ 2008-11-10 9:46 ` martin rudalics 2008-11-17 10:30 ` bug#1322: marked as done (dedicated *Help* and M-x help-for-help) Emacs bug Tracking System 1 sibling, 0 replies; 8+ messages in thread From: martin rudalics @ 2008-11-10 9:46 UTC (permalink / raw) To: 1322; +Cc: jm3 > `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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: marked as done (dedicated *Help* and M-x help-for-help) 2008-11-10 4:47 ` bug#1322: dedicated *Help* and M-x help-for-help David Reitter 2008-11-10 9:46 ` martin rudalics @ 2008-11-17 10:30 ` Emacs bug Tracking System 1 sibling, 0 replies; 8+ messages in thread From: Emacs bug Tracking System @ 2008-11-17 10:30 UTC (permalink / raw) To: martin rudalics [-- Attachment #1: Type: text/plain, Size: 845 bytes --] Your message dated Mon, 17 Nov 2008 11:19:09 +0100 with message-id <4921451D.7060006@gmx.at> and subject line Re: bug#1322: dedicated *Help* and M-x help-for-help has caused the Emacs bug report #1322, regarding dedicated *Help* and M-x help-for-help to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1322: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1322 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 7022 bytes --] From: David Reitter <david.reitter@gmail.com> To: emacs-pretest-bug@gnu.org Cc: jm3@jm3.net Subject: dedicated *Help* and M-x help-for-help Date: Sun, 9 Nov 2008 23:47:00 -0500 Message-ID: <EC7340CC-AD2A-477B-AF13-7231AB0E8B46@gmail.com> `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'' [-- Attachment #3: Type: message/rfc822, Size: 2003 bytes --] From: martin rudalics <rudalics@gmx.at> To: 1322-done@emacsbugs.donarmstrong.com Cc: David Reitter <david.reitter@gmail.com>, jm3@jm3.net Subject: Re: bug#1322: dedicated *Help* and M-x help-for-help Date: Mon, 17 Nov 2008 11:19:09 +0100 Message-ID: <4921451D.7060006@gmx.at> > `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@gmx.at> * help-macro.el (make-help-screen): Don't iconify selected frame. (Bug#1322) Thanks for the report, martin. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: dedicated *Help* and M-x help-for-help @ 2008-11-10 10:33 Geoff Gole 2008-11-10 14:57 ` Drew Adams 2008-11-10 17:06 ` martin rudalics 0 siblings, 2 replies; 8+ messages in thread From: Geoff Gole @ 2008-11-10 10:33 UTC (permalink / raw) To: 1322, David Reitter 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: dedicated *Help* and M-x help-for-help 2008-11-10 10:33 bug#1322: dedicated *Help* and M-x help-for-help Geoff Gole @ 2008-11-10 14:57 ` Drew Adams 2008-11-10 17:06 ` martin rudalics 1 sibling, 0 replies; 8+ messages in thread From: Drew Adams @ 2008-11-10 14:57 UTC (permalink / raw) To: 'Geoff Gole', 1322, 'David Reitter' > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: dedicated *Help* and M-x help-for-help 2008-11-10 10:33 bug#1322: dedicated *Help* and M-x help-for-help Geoff Gole 2008-11-10 14:57 ` Drew Adams @ 2008-11-10 17:06 ` martin rudalics 2008-11-11 2:28 ` Geoff Gole 1 sibling, 1 reply; 8+ messages in thread From: martin rudalics @ 2008-11-10 17:06 UTC (permalink / raw) To: Geoff Gole, 1322 > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: dedicated *Help* and M-x help-for-help 2008-11-10 17:06 ` martin rudalics @ 2008-11-11 2:28 ` Geoff Gole 2008-11-11 9:41 ` martin rudalics 0 siblings, 1 reply; 8+ messages in thread From: Geoff Gole @ 2008-11-11 2:28 UTC (permalink / raw) To: martin rudalics, 1322 > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#1322: dedicated *Help* and M-x help-for-help 2008-11-11 2:28 ` Geoff Gole @ 2008-11-11 9:41 ` martin rudalics 0 siblings, 0 replies; 8+ messages in thread From: martin rudalics @ 2008-11-11 9:41 UTC (permalink / raw) To: Geoff Gole; +Cc: 1322 > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-11-17 10:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <4921451D.7060006@gmx.at> 2008-11-10 4:47 ` bug#1322: dedicated *Help* and M-x help-for-help David Reitter 2008-11-10 9:46 ` martin rudalics 2008-11-17 10:30 ` bug#1322: marked as done (dedicated *Help* and M-x help-for-help) Emacs bug Tracking System 2008-11-10 10:33 bug#1322: dedicated *Help* and M-x help-for-help Geoff Gole 2008-11-10 14:57 ` Drew Adams 2008-11-10 17:06 ` martin rudalics 2008-11-11 2:28 ` Geoff Gole 2008-11-11 9:41 ` martin rudalics
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).