* Re: auto-insert help-buffer [not found] <45D967C4.5060104@easy-emacs.de> @ 2007-03-08 16:23 ` Chong Yidong 2007-03-08 21:48 ` Richard Stallman 0 siblings, 1 reply; 6+ messages in thread From: Chong Yidong @ 2007-03-08 16:23 UTC (permalink / raw) To: emacs-devel; +Cc: Andreas Roehler > emacs -q > M-x auto-insert > Prompt for keyword > C-h > > opens a help-buffer with descriptions, but without the > corresponding keywords visible. > > This buffer vanishes, when clicked by mouse. > > => > > scroll-bar-toolkit-scroll: Wrong type argument An easier way is to evaluate (let ((minibuffer-help-form "You are inserting a skeleton.")) (read-string "Foo: " "Bar")) type C-h, click on the help window, and observe the error. This seems to be the result of the following code in keyboard.c:3316. Basically, we record-unwind-protect the current window configuration before launching the help form, which creates a new window. Therefore, when the mouse click on the temporary window comes through, the unbind_to first removes the window, then runs the mouse bindings, which fail because the window is no longer live. One possibility is to remove the unwind protect; the other is to check in the mouse-click functions whether the desired window is live or not. Which solution is preferable? /* Process the help character specially if enabled */ if (!NILP (Vhelp_form) && help_char_p (c)) { Lisp_Object tem0; count = SPECPDL_INDEX (); record_unwind_protect (Fset_window_configuration, Fcurrent_window_configuration (Qnil)); tem0 = Feval (Vhelp_form); if (STRINGP (tem0)) internal_with_output_to_temp_buffer ("*Help*", print_help, tem0); cancel_echoing (); do c = read_char (0, 0, 0, Qnil, 0, NULL); while (BUFFERP (c)); /* Remove the help from the frame */ unbind_to (count, Qnil); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: auto-insert help-buffer 2007-03-08 16:23 ` auto-insert help-buffer Chong Yidong @ 2007-03-08 21:48 ` Richard Stallman 2007-03-09 2:06 ` Chong Yidong 0 siblings, 1 reply; 6+ messages in thread From: Richard Stallman @ 2007-03-08 21:48 UTC (permalink / raw) To: Chong Yidong; +Cc: andreas.roehler, emacs-devel We need to look for the solution in terms of what the user wants in the various cases. One possibility is to remove the unwind protect; the other is to check in the mouse-click functions whether the desired window is live or not. Which solution is preferable? Both of them will make users unhappy. The first would mean that typing SPC no longer gets rid of the help window. Clearly bad. The second will avoid the error in these mouse commands, but it won't make the commands actually _work_. So the user will be disappointed. If a user clicks on the help buffer, he wants to operate on it. So _in that case_, that window should not vanish. It should stay around to be operated on. Here's a way to implement it: If the event that was read is a mouse event, and the buffer it's on is the help buffer, it should discard the unwind-protect without restoring the old window config. If the event is not a mouse event, it should do what it does now. It's not perfectly simple, but it is not very complex either. Can you implement that? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: auto-insert help-buffer 2007-03-08 21:48 ` Richard Stallman @ 2007-03-09 2:06 ` Chong Yidong 2007-03-09 21:27 ` Richard Stallman 0 siblings, 1 reply; 6+ messages in thread From: Chong Yidong @ 2007-03-09 2:06 UTC (permalink / raw) To: rms; +Cc: andreas.roehler, emacs-devel Richard Stallman <rms@gnu.org> writes: > If the event that was read is a mouse event, and the buffer it's on is > the help buffer, it should discard the unwind-protect without > restoring the old window config. > > If the event is not a mouse event, it should do what it does now. > > It's not perfectly simple, but it is not very complex either. > > Can you implement that? How bout this (modulo comments)? I cancel the window config unwinding as long as the user clicks anywhere using the mouse, not just the help window---it's too much trouble trying to identify the help window. I think this is an acceptable compromise. *** emacs/src/keyboard.c.~1.892.~ 2007-01-27 13:29:49.000000000 -0500 --- emacs/src/keyboard.c 2007-03-08 21:04:16.000000000 -0500 *************** *** 2450,2455 **** --- 2450,2466 ---- static Lisp_Object kbd_buffer_get_event (); static void record_char (); + static Lisp_Object help_form_saved_window_configs; + static Lisp_Object + read_char_help_form_unwind (arg) + { + Lisp_Object window_config = XCAR (help_form_saved_window_configs); + help_form_saved_window_configs = XCDR (help_form_saved_window_configs); + if (!NILP (window_config)) + Fset_window_configuration (window_config); + return Qnil; + } + #ifdef MULTI_KBOARD static jmp_buf wrong_kboard_jmpbuf; #endif *************** *** 3319,3326 **** Lisp_Object tem0; count = SPECPDL_INDEX (); ! record_unwind_protect (Fset_window_configuration, ! Fcurrent_window_configuration (Qnil)); tem0 = Feval (Vhelp_form); if (STRINGP (tem0)) --- 3330,3339 ---- Lisp_Object tem0; count = SPECPDL_INDEX (); ! record_unwind_protect (read_char_help_form_unwind, Qnil); ! help_form_saved_window_configs ! = Fcons (Fcurrent_window_configuration (Qnil), ! help_form_saved_window_configs); tem0 = Feval (Vhelp_form); if (STRINGP (tem0)) *************** *** 3328,3334 **** cancel_echoing (); do ! c = read_char (0, 0, 0, Qnil, 0, NULL); while (BUFFERP (c)); /* Remove the help from the frame */ unbind_to (count, Qnil); --- 3341,3352 ---- cancel_echoing (); do ! { ! c = read_char (0, 0, 0, Qnil, 0, NULL); ! if (EVENT_HAS_PARAMETERS (c) ! && EQ (EVENT_HEAD_KIND (EVENT_HEAD (c)), Qmouse_click)) ! XSETCAR (help_form_saved_window_configs, Qnil); ! } while (BUFFERP (c)); /* Remove the help from the frame */ unbind_to (count, Qnil); *************** *** 11335,11340 **** --- 11353,11361 ---- menu_bar_items_vector = Qnil; staticpro (&menu_bar_items_vector); + help_form_saved_window_configs = Qnil; + staticpro (&help_form_saved_window_configs); + defsubr (&Scurrent_idle_time); defsubr (&Sevent_convert_list); defsubr (&Sread_key_sequence); ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: auto-insert help-buffer 2007-03-09 2:06 ` Chong Yidong @ 2007-03-09 21:27 ` Richard Stallman 2007-03-10 4:48 ` Chong Yidong 0 siblings, 1 reply; 6+ messages in thread From: Richard Stallman @ 2007-03-09 21:27 UTC (permalink / raw) To: Chong Yidong; +Cc: andreas.roehler, emacs-devel ! record_unwind_protect (read_char_help_form_unwind, Qnil); ! help_form_saved_window_configs ! = Fcons (Fcurrent_window_configuration (Qnil), ! help_form_saved_window_configs); I would call record_unwind_protect after pushing the new element. I cancel the window config unwinding as long as the user clicks anywhere using the mouse, not just the help window---it's too much trouble trying to identify the help window. How about if you assume that the most recently displayed window is the help window? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: auto-insert help-buffer 2007-03-09 21:27 ` Richard Stallman @ 2007-03-10 4:48 ` Chong Yidong 2007-03-11 4:23 ` Richard Stallman 0 siblings, 1 reply; 6+ messages in thread From: Chong Yidong @ 2007-03-10 4:48 UTC (permalink / raw) To: rms; +Cc: andreas.roehler, emacs-devel Richard Stallman <rms@gnu.org> writes: > ! record_unwind_protect (read_char_help_form_unwind, Qnil); > ! help_form_saved_window_configs > ! = Fcons (Fcurrent_window_configuration (Qnil), > ! help_form_saved_window_configs); > > I would call record_unwind_protect after pushing the new element. > > I cancel the window config unwinding as long as the user clicks > anywhere using the mouse, not just the help window---it's too much > trouble trying to identify the help window. > > How about if you assume that the most recently displayed window > is the help window? It's not foolproof, since display-buffer can reuse an existing window, or pop up a new frame, or (with the appropriate user customizations) something else entirely. I think it's reasonable to expect that if the user clicks somewhere, he or she does not expect the window configuration to abruptly change "under the mouse pointer". ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: auto-insert help-buffer 2007-03-10 4:48 ` Chong Yidong @ 2007-03-11 4:23 ` Richard Stallman 0 siblings, 0 replies; 6+ messages in thread From: Richard Stallman @ 2007-03-11 4:23 UTC (permalink / raw) To: Chong Yidong; +Cc: andreas.roehler, emacs-devel I think it's reasonable to expect that if the user clicks somewhere, he or she does not expect the window configuration to abruptly change "under the mouse pointer". That does seem plausible. Ok. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-03-11 4:23 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <45D967C4.5060104@easy-emacs.de> 2007-03-08 16:23 ` auto-insert help-buffer Chong Yidong 2007-03-08 21:48 ` Richard Stallman 2007-03-09 2:06 ` Chong Yidong 2007-03-09 21:27 ` Richard Stallman 2007-03-10 4:48 ` Chong Yidong 2007-03-11 4:23 ` Richard Stallman
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).