* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown @ 2019-12-17 6:49 ynyaaa 2019-12-17 7:41 ` Eli Zaretskii 2019-12-17 11:55 ` ynyaaa 0 siblings, 2 replies; 17+ messages in thread From: ynyaaa @ 2019-12-17 6:49 UTC (permalink / raw) To: 38645 Evaluating the form below, the minibuffer window has 2-line height. (progn (message "1\n2") (read-string "input: ")) In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32) of 2019-08-29 built on CIRROCUMULUS Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd Windowing system distributor 'Microsoft Corp.', version 6.3.9600 Recent messages: C-h C-b is undefined Configured using: 'configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install 'CFLAGS=-O2 -static -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2 Important settings: value of $LANG: JPN locale-coding-system: cp932 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date mule-util japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 99630 10477) (symbols 48 20226 1) (miscs 40 42 193) (strings 32 29779 1438) (string-bytes 1 765275) (vectors 16 14542) (vector-slots 8 572211 11846) (floats 8 51 191) (intervals 56 269 16) (buffers 992 12)) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-17 6:49 bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown ynyaaa @ 2019-12-17 7:41 ` Eli Zaretskii 2019-12-17 11:55 ` ynyaaa 1 sibling, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2019-12-17 7:41 UTC (permalink / raw) To: 38645, ynyaaa On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa@gmail.com wrote: > > Evaluating the form below, the minibuffer window has 2-line height. > > (progn > (message "1\n2") > (read-string "input: ")) That's a feature: by default the mini-window only grows automatically, and doesn't get reset to its original 1 line until the echo area is cleared. If you don't like this, customize resize-mini-windows to the value t, or bind it temporarily while running code such as in the recipe. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-17 6:49 bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown ynyaaa 2019-12-17 7:41 ` Eli Zaretskii @ 2019-12-17 11:55 ` ynyaaa 2019-12-17 12:07 ` Eli Zaretskii 1 sibling, 1 reply; 17+ messages in thread From: ynyaaa @ 2019-12-17 11:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 38645 Eli Zaretskii <eliz@gnu.org> writes: > On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa@gmail.com wrote: >> >> Evaluating the form below, the minibuffer window has 2-line height. >> >> (progn >> (message "1\n2") >> (read-string "input: ")) > > > That's a feature: by default the mini-window only grows automatically, > and doesn't get reset to its original 1 line until the echo area is > cleared. If you don't like this, customize resize-mini-windows to the > value t, or bind it temporarily while running code such as in the > recipe. This may happen with unrelated commands. Commands below shows an example. Please input M-x as one key event, not ESC x. M-: "1\n2" RET M-x ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-17 11:55 ` ynyaaa @ 2019-12-17 12:07 ` Eli Zaretskii 2019-12-18 10:52 ` ynyaaa 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2019-12-17 12:07 UTC (permalink / raw) To: ynyaaa; +Cc: 38645 On December 17, 2019 1:55:48 PM GMT+02:00, ynyaaa@gmail.com wrote: > Eli Zaretskii <eliz@gnu.org> writes: > > > On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa@gmail.com wrote: > >> > > > That's a feature: by default the mini-window only grows > automatically, > > and doesn't get reset to its original 1 line until the echo area is > > cleared. If you don't like this, customize resize-mini-windows to > the > > value t, or bind it temporarily while running code such as in the > > recipe. > > This may happen with unrelated commands. > Commands below shows an example. > Please input M-x as one key event, not ESC x. > > M-: "1\n2" RET > M-x When I type this with resize-mini-windows set to t, typing M-x causes the mini-window to shrink back to its original one-line height. So I don't think I understand the complaint. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-17 12:07 ` Eli Zaretskii @ 2019-12-18 10:52 ` ynyaaa 2019-12-18 16:31 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: ynyaaa @ 2019-12-18 10:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 38645 Eli Zaretskii <eliz@gnu.org> writes: > On December 17, 2019 1:55:48 PM GMT+02:00, ynyaaa@gmail.com wrote: >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > On December 17, 2019 8:49:17 AM GMT+02:00, ynyaaa@gmail.com wrote: >> >> >> >> > That's a feature: by default the mini-window only grows >> automatically, >> > and doesn't get reset to its original 1 line until the echo area is >> > cleared. If you don't like this, customize resize-mini-windows to >> the >> > value t, or bind it temporarily while running code such as in the >> > recipe. >> >> This may happen with unrelated commands. >> Commands below shows an example. >> Please input M-x as one key event, not ESC x. >> >> M-: "1\n2" RET >> M-x > > When I type this with resize-mini-windows set to t, typing M-x causes > the mini-window to shrink back to its original one-line height. So I > don't think I understand the complaint. Evaluate the form below and type 3 2 1, minibuffer window shrinks each time. This behavior is inconsistent with read-string. To check echo area contents just before read-string, type 3 4 and the tmp variable value is nil, which indicates that the echo area has been cleared without shrinking the minibuffer window. (let ((buf (generate-new-buffer "tmp")) (map (make-sparse-keymap))) (switch-to-buffer buf) (define-key map "1" (lambda () (interactive) (message "1"))) (define-key map "2" (lambda () (interactive) (message "a\nb"))) (define-key map "3" (lambda () (interactive) (message "A\nB\nC"))) (define-key map "4" (lambda () (interactive) (let ((tmp (current-message))) (read-string "input: ") (message "tmp: %s" tmp)))) (use-local-map map)) By the way, read-string with empty PROMPT make the minibuffer window shrink. (progn (message "1\n2") (read-string "")) Also it make the window shrink when all the minibuffer content is deleted, even though read-string is not finished. M-: (read-string "") RET C-q C-j C-q C-j DEL DEL ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-18 10:52 ` ynyaaa @ 2019-12-18 16:31 ` Eli Zaretskii 2019-12-20 2:16 ` ynyaaa 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2019-12-18 16:31 UTC (permalink / raw) To: ynyaaa; +Cc: 38645 > From: ynyaaa@gmail.com > Cc: bug-gnu-emacs@gnu.org, 38645@debbugs.gnu.org > Date: Wed, 18 Dec 2019 19:52:44 +0900 > > Evaluate the form below and type 3 2 1, minibuffer window shrinks each > time. This behavior is inconsistent with read-string. > To check echo area contents just before read-string, type 3 4 > and the tmp variable value is nil, which indicates that the echo area > has been cleared without shrinking the minibuffer window. > > (let ((buf (generate-new-buffer "tmp")) > (map (make-sparse-keymap))) > (switch-to-buffer buf) > (define-key map "1" (lambda () (interactive) (message "1"))) > (define-key map "2" (lambda () (interactive) (message "a\nb"))) > (define-key map "3" (lambda () (interactive) (message "A\nB\nC"))) > (define-key map "4" (lambda () (interactive) > (let ((tmp (current-message))) > (read-string "input: ") > (message "tmp: %s" tmp)))) > (use-local-map map)) > > > By the way, read-string with empty PROMPT make the minibuffer window > shrink. > > (progn > (message "1\n2") > (read-string "")) > > Also it make the window shrink when all the minibuffer content is > deleted, even though read-string is not finished. > > M-: (read-string "") RET > C-q C-j > C-q C-j > DEL > DEL I still fail to see the problem in these use cases. Is the problem that from your POV the behavior wrt shrinking the mini-window happens sometimes, but not always? If so, this is not a bug: by default Emacs does not try too hard to do so, although when a command finishes and Emacs runs a full redisplay cycle, it usually does shrink it. If you set resize-mini-windows to t, it tries harder, and will shrink in many cases even in the middle of a running command. Also please keep in mind that the mini-window shows not only the echo area, but also the minibuffer (when it's active), so the fact that the echo-area message has been cleared does not yet mean the mini-window can be shrunk -- if the minibuffer is active, it usually won't be. At this point please tell if you have real-life use cases where this behavior causes real problems, like concealing some part of the echo-area message, and if so, please describe those real-life use cases. If this is just about consistency, I tend not to touch this area of the display engine, as it is somewhat delicate and easy to break. Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-18 16:31 ` Eli Zaretskii @ 2019-12-20 2:16 ` ynyaaa 2019-12-26 20:49 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: ynyaaa @ 2019-12-20 2:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 38645 Eli Zaretskii <eliz@gnu.org> writes: >> From: ynyaaa@gmail.com >> Cc: bug-gnu-emacs@gnu.org, 38645@debbugs.gnu.org >> Date: Wed, 18 Dec 2019 19:52:44 +0900 >> >> Evaluate the form below and type 3 2 1, minibuffer window shrinks each >> time. This behavior is inconsistent with read-string. >> To check echo area contents just before read-string, type 3 4 >> and the tmp variable value is nil, which indicates that the echo area >> has been cleared without shrinking the minibuffer window. >> >> (let ((buf (generate-new-buffer "tmp")) >> (map (make-sparse-keymap))) >> (switch-to-buffer buf) >> (define-key map "1" (lambda () (interactive) (message "1"))) >> (define-key map "2" (lambda () (interactive) (message "a\nb"))) >> (define-key map "3" (lambda () (interactive) (message "A\nB\nC"))) >> (define-key map "4" (lambda () (interactive) >> (let ((tmp (current-message))) >> (read-string "input: ") >> (message "tmp: %s" tmp)))) >> (use-local-map map)) >> >> >> By the way, read-string with empty PROMPT make the minibuffer window >> shrink. >> >> (progn >> (message "1\n2") >> (read-string "")) >> >> Also it make the window shrink when all the minibuffer content is >> deleted, even though read-string is not finished. >> >> M-: (read-string "") RET >> C-q C-j >> C-q C-j >> DEL >> DEL > > I still fail to see the problem in these use cases. Is the problem > that from your POV the behavior wrt shrinking the mini-window happens > sometimes, but not always? If so, this is not a bug: by default Emacs > does not try too hard to do so, although when a command finishes and > Emacs runs a full redisplay cycle, it usually does shrink it. If you > set resize-mini-windows to t, it tries harder, and will shrink in many > cases even in the middle of a running command. > > Also please keep in mind that the mini-window shows not only the echo > area, but also the minibuffer (when it's active), so the fact that the > echo-area message has been cleared does not yet mean the mini-window > can be shrunk -- if the minibuffer is active, it usually won't be. > > At this point please tell if you have real-life use cases where this > behavior causes real problems, like concealing some part of the > echo-area message, and if so, please describe those real-life use > cases. If this is just about consistency, I tend not to touch this > area of the display engine, as it is somewhat delicate and easy to > break. > > Thanks. With (setq resize-mini-windows t), the key sequence below shows message in one-line window. Then input motion commands and the minibuffer is redisplayed in one-line window. Eval: prompt is hidden. M-: C-q C-j ?a C-x C-e ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-20 2:16 ` ynyaaa @ 2019-12-26 20:49 ` Eli Zaretskii 2019-12-27 9:12 ` martin rudalics 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2019-12-26 20:49 UTC (permalink / raw) To: ynyaaa, martin rudalics; +Cc: 38645 > From: ynyaaa@gmail.com > Cc: 38645@debbugs.gnu.org > Date: Fri, 20 Dec 2019 11:16:31 +0900 > > With (setq resize-mini-windows t), the key sequence below shows message > in one-line window. Then input motion commands and the minibuffer is > redisplayed in one-line window. Eval: prompt is hidden. > > M-: > C-q C-j > ?a > C-x C-e Martin, what do you think about the following fix? Is it correct, and if so, safe enough for the release branch? diff --git a/src/xdisp.c b/src/xdisp.c index 3080f8920a..438267350f 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -11562,7 +11562,15 @@ resize_mini_window (struct window *w, bool exact_p) SET_MARKER_FROM_TEXT_POS (w->start, start); - if (EQ (Vresize_mini_windows, Qgrow_only)) + if (EQ (Vresize_mini_windows, Qgrow_only) + /* Don't automatically shrink the mini-window, even if + resize-mini-windows is t, if we are displaying an + echo-area message while the minibuffer is active. */ + || (minibuf_level > 0 + && WINDOW_LIVE_P (minibuf_window) + && XWINDOW (minibuf_window) == w + && !NILP (echo_area_buffer[0]) + && EQ (echo_area_window, minibuf_window))) { /* Let it grow only, until we display an empty message, in which case the window shrinks again. */ ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-26 20:49 ` Eli Zaretskii @ 2019-12-27 9:12 ` martin rudalics 2019-12-27 9:21 ` Eli Zaretskii 2019-12-29 14:15 ` Eli Zaretskii 0 siblings, 2 replies; 17+ messages in thread From: martin rudalics @ 2019-12-27 9:12 UTC (permalink / raw) To: Eli Zaretskii, ynyaaa; +Cc: 38645 > Martin, what do you think about the following fix? Is it correct, and > if so, safe enough for the release branch? It seems "correct" in the sense that our doc of 'resize-mini-windows' nowhere contradicts any such interpretation. It should be "safe" in the sense that failing to always resize the minibuffer window exactly and falling back on 'grow-only' should not do any harm since otherwise we'd have a bug in the 'grow-only' part of the code. But I'm too silly to understand why the minibuffer window does not re-grow in the first place after having shown the result of C-x C-e. Can you enlighten me? martin, who just noted that the recently added (to master) Lisp_Object str = build_string ("Command attempted to use minibuffer" "while in minibuffer"); produces "Command attempted to use minibufferwhile in minibuffer" martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-27 9:12 ` martin rudalics @ 2019-12-27 9:21 ` Eli Zaretskii 2019-12-27 9:46 ` martin rudalics 2019-12-29 14:15 ` Eli Zaretskii 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2019-12-27 9:21 UTC (permalink / raw) To: martin rudalics; +Cc: ynyaaa, 38645 > Cc: 38645@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Fri, 27 Dec 2019 10:12:33 +0100 > > But I'm too silly to understand why the minibuffer window does not > re-grow in the first place after having shown the result of C-x C-e. > Can you enlighten me? Re-grow upon which event? If you do nothing, the message from "C-x C-e" stays displayed indefinitely. If you mean why it doesn't re-grow upon some keystroke (which removes the message), I guess we are lacking a call to resize_echo_area_exactly in some place. Regardless, I think keeping the prompt visible is a better behavior. And yes, we should probably document this caveat, although I cannot imagine what application would like the current behavior. > martin, who just noted that the recently added (to master) > > Lisp_Object str = build_string ("Command attempted to use minibuffer" > "while in minibuffer"); > > produces > > "Command attempted to use minibufferwhile in minibuffer" Hope you've already fixed it. Thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-27 9:21 ` Eli Zaretskii @ 2019-12-27 9:46 ` martin rudalics 2019-12-27 10:29 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2019-12-27 9:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ynyaaa, 38645 >> But I'm too silly to understand why the minibuffer window does not >> re-grow in the first place after having shown the result of C-x C-e. >> Can you enlighten me? > > Re-grow upon which event? If you do nothing, the message from "C-x C-e" > stays displayed indefinitely. Not here. After a short pause I get the one line ?a back. > If you mean why it doesn't re-grow upon some keystroke (which removes > the message), I guess we are lacking a call to > resize_echo_area_exactly in some place. I guess so too. > Regardless, I think keeping the prompt visible is a better behavior. But while showing the result of C-x C-e (97 ...) it doesn't show any prompt here, just an empty trailing line. What am I missing? > And yes, we should probably document this caveat, although I cannot > imagine what application would like the current behavior. > >> martin, who just noted that the recently added (to master) >> >> Lisp_Object str = build_string ("Command attempted to use minibuffer" >> "while in minibuffer"); >> >> produces >> >> "Command attempted to use minibufferwhile in minibuffer" > > Hope you've already fixed it. I cannot reliably push these days. I have to first rebuild my git environment and probably will wait with that until Glen has fixed the copyright headers to avoid excessive re-compilations. My machine is getting a bit weak for so much work ... martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-27 9:46 ` martin rudalics @ 2019-12-27 10:29 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2019-12-27 10:29 UTC (permalink / raw) To: martin rudalics; +Cc: 38645 > Cc: ynyaaa@gmail.com, 38645@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Fri, 27 Dec 2019 10:46:57 +0100 > > >> martin, who just noted that the recently added (to master) > >> > >> Lisp_Object str = build_string ("Command attempted to use minibuffer" > >> "while in minibuffer"); > >> > >> produces > >> > >> "Command attempted to use minibufferwhile in minibuffer" > > > > Hope you've already fixed it. > > I cannot reliably push these days. OK, pushed. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-27 9:12 ` martin rudalics 2019-12-27 9:21 ` Eli Zaretskii @ 2019-12-29 14:15 ` Eli Zaretskii 2019-12-29 18:33 ` martin rudalics 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2019-12-29 14:15 UTC (permalink / raw) To: martin rudalics; +Cc: ynyaaa, 38645 > Cc: 38645@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Fri, 27 Dec 2019 10:12:33 +0100 > > > Martin, what do you think about the following fix? Is it correct, and > > if so, safe enough for the release branch? > > It seems "correct" in the sense that our doc of 'resize-mini-windows' > nowhere contradicts any such interpretation. It should be "safe" in > the sense that failing to always resize the minibuffer window exactly > and falling back on 'grow-only' should not do any harm since otherwise > we'd have a bug in the 'grow-only' part of the code. > > But I'm too silly to understand why the minibuffer window does not > re-grow in the first place after having shown the result of C-x C-e. > Can you enlighten me? I hope the following alternative patch will answer that question. Comments are welcome. diff --git a/src/keyboard.c b/src/keyboard.c index 4cf1f64b48..a04f1f77de 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -1318,6 +1318,11 @@ command_loop_1 (void) message1 (0); safe_run_hooks (Qecho_area_clear_hook); + /* We cleared the echo area, and the minibuffer will now + show, so resize the mini-window in case the minibuffer + needs more or less space than the echo area. */ + resize_mini_window (XWINDOW (minibuf_window), false); + unbind_to (count, Qnil); /* If a C-g came in before, treat it as input now. */ @@ -2989,6 +2994,16 @@ read_char (int commandflag, Lisp_Object map, { safe_run_hooks (Qecho_area_clear_hook); clear_message (1, 0); + /* If we were showing the echo-area message on top of an + active minibuffer, resize the mini-window, since the + minibuffer may need more or less space than the echo area + we've just wiped. */ + if (minibuf_level + && EQ (minibuf_window, echo_area_window) + /* The case where minibuffer-message-timeout is a number + was already handled near the beginning of this function. */ + && !NUMBERP (Vminibuffer_message_timeout)) + resize_mini_window (XWINDOW (minibuf_window), false); } else if (FUNCTIONP (Vclear_message_function)) clear_message (1, 0); ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-29 14:15 ` Eli Zaretskii @ 2019-12-29 18:33 ` martin rudalics 2019-12-29 18:50 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2019-12-29 18:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ynyaaa, 38645 > I hope the following alternative patch will answer that question. It cleanly fixes the OP's problem. Did you check whether any of the other clear_message calls would need a similar treatment? > + /* The case where minibuffer-message-timeout is a number > + was already handled near the beginning of this function. */ Can you tell where? I didn't find it. Thanks, martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-29 18:33 ` martin rudalics @ 2019-12-29 18:50 ` Eli Zaretskii 2019-12-29 19:30 ` martin rudalics 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2019-12-29 18:50 UTC (permalink / raw) To: martin rudalics; +Cc: ynyaaa, 38645 > Cc: ynyaaa@gmail.com, 38645@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Sun, 29 Dec 2019 19:33:43 +0100 > > > I hope the following alternative patch will answer that question. > > It cleanly fixes the OP's problem. Did you check whether any of the > other clear_message calls would need a similar treatment? Which ones? > > + /* The case where minibuffer-message-timeout is a number > > + was already handled near the beginning of this function. */ > > Can you tell where? I didn't find it. Oops, sorry, it's at the beginning of command_loop_1. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-29 18:50 ` Eli Zaretskii @ 2019-12-29 19:30 ` martin rudalics 2019-12-30 16:07 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2019-12-29 19:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ynyaaa, 38645 >> Did you check whether any of the >> other clear_message calls would need a similar treatment? > > Which ones? Maybe the last one in read_char itself. But I don't understand well what we are doing there. martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown 2019-12-29 19:30 ` martin rudalics @ 2019-12-30 16:07 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2019-12-30 16:07 UTC (permalink / raw) To: martin rudalics; +Cc: ynyaaa, 38645-done > Cc: ynyaaa@gmail.com, 38645@debbugs.gnu.org > From: martin rudalics <rudalics@gmx.at> > Date: Sun, 29 Dec 2019 20:30:47 +0100 > > >> Did you check whether any of the > >> other clear_message calls would need a similar treatment? > > > > Which ones? > > Maybe the last one in read_char itself. But I don't understand well what > we are doing there. We are evidently clearing the echo area if the input method left something there. But I couldn't create a situation where there was anything left to do after the input method finished its job, not by turning on an input method in the active minibuffer. Quail has its own ideas about handling this situation; see quail-minibuffer-message and quail-show-guidance. In particular, it arranges for the guidance to appear on the second line of the mini-window (the first one being where you type at the prompt), and never shows more than one line of candidates for input there (you need to scroll with up- and down-arrows). And when input is done, the mini-window resizes back. So if someone knows how to trigger a mini-window resizing problems related to input methods, please show a recipe (and reopen the bug). Meanwhile, I've installed the fix and I'm closing this bug report. Thanks for the feedback. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-12-30 16:07 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-12-17 6:49 bug#38645: 26.3; minibuffer input is called with multi-line window when multi-line message is shown ynyaaa 2019-12-17 7:41 ` Eli Zaretskii 2019-12-17 11:55 ` ynyaaa 2019-12-17 12:07 ` Eli Zaretskii 2019-12-18 10:52 ` ynyaaa 2019-12-18 16:31 ` Eli Zaretskii 2019-12-20 2:16 ` ynyaaa 2019-12-26 20:49 ` Eli Zaretskii 2019-12-27 9:12 ` martin rudalics 2019-12-27 9:21 ` Eli Zaretskii 2019-12-27 9:46 ` martin rudalics 2019-12-27 10:29 ` Eli Zaretskii 2019-12-29 14:15 ` Eli Zaretskii 2019-12-29 18:33 ` martin rudalics 2019-12-29 18:50 ` Eli Zaretskii 2019-12-29 19:30 ` martin rudalics 2019-12-30 16:07 ` Eli Zaretskii
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).