unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: ndame <emacsuser@freemail.hu>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Intelligent stacking of messages in the echo area
Date: Thu, 30 Jan 2020 00:54:12 +0200	[thread overview]
Message-ID: <87tv4dlvqj.fsf@mail.linkov.net> (raw)
In-Reply-To: <87blrxdl2w.fsf@localhost> (Ihor Radchenko's message of "Wed, 25 Dec 2019 13:35:03 +0800")

>> Maybe this is because multi-line messages resize the echo-area window
>> every time a new message line is added (when resize-mini-windows is non-nil),
>> so height changes of the echo-area window invoke window-configuration-change-hook.
>
> I suspect that it is exactly the case.
> However, window-configuration-change-hook is not fired so frequently in
> other functions like split-window.
> Most likely, it is because window-configuration-change-hook is only
> called during redisplay. From its docstring:
> "Functions called during redisplay when window configuration has
> changed."
>
> I guess that resizing echo-area forcefully calls redisplay and hence
> window-configuration-change-hook, thus slowing down command execution.

To avoid continual resizing of echo-area when new messages arrive,
maybe 'resize-mini-windows' should allow setting it to a fixed number
of lines, so e.g. (setq resize-mini-windows 10) would mean
that the height of the echo-area will be kept always at 10 lines,
even when it displays less lines.

If this is impossible to do then a possible workaround is to emulate this
in set-multi-message by inserting empty lines to fill the height to
a fixed amount of lines.  This is a possible change over the previous patch:

@@ -452,7 +474,11 @@ set-multi-message
       (push (vector (float-time) message (not message-log-max)) multi-message-list)
       (when (> (length multi-message-list) multi-message-max)
         (setf (nthcdr multi-message-max multi-message-list) nil)))
-    (mapconcat (lambda (m) (aref m 1))
-               (reverse multi-message-list)
+    (mapconcat (lambda (m) (if (stringp m) m (aref m 1)))
+               (append (reverse multi-message-list)
+                       ;; Fill remaining space by empty lines to keep fixed height
+                       ;; of the echo-area to avoid continual resizing of echo-area
+                       ;; when new messages arrive.
+                       (make-list (- multi-message-max (length multi-message-list)) ""))
                multi-message-separator)))

Then another problem is that clear-message doesn't keep fixed height of echo-area.
Maybe an additional workaround would be to issue an empty message that
will be filled by empty lines in set-multi-message for clear-message as well:

(defun clear-multi-message--wrapper (orig-fun)
  (funcall orig-fun)
  (setq multi-message-list nil)
  (message "\n"))

(setq clear-message-function 'clear-minibuffer-message)
(add-function :around clear-message-function #'clear-multi-message--wrapper)



  reply	other threads:[~2020-01-29 22:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-31  5:35 Intelligent stacking of messages in the echo area ndame
2019-08-31  9:46 ` Marcin Borkowski
2019-12-21 22:07 ` Juri Linkov
2019-12-22  3:30   ` Eli Zaretskii
2019-12-23  2:59   ` Richard Stallman
2019-12-23 22:46     ` Juri Linkov
2019-12-23  3:50   ` Ihor Radchenko
2019-12-23 13:38     ` Eli Zaretskii
2019-12-24  9:24       ` Ihor Radchenko
2019-12-24 15:36         ` Eli Zaretskii
2019-12-25  4:21           ` Ihor Radchenko
2019-12-23 22:47     ` Juri Linkov
2019-12-24  9:40       ` Ihor Radchenko
2019-12-24 15:43         ` Eli Zaretskii
2019-12-24 17:32           ` Ihor Radchenko
2019-12-25  0:15         ` Juri Linkov
2019-12-25  5:35           ` Ihor Radchenko
2020-01-29 22:54             ` Juri Linkov [this message]
2020-01-24 10:14       ` Eric S Fraga
2020-01-28 22:34         ` Juri Linkov
2020-01-29 22:41           ` Juri Linkov
2020-01-29 23:53             ` Stefan Monnier
2020-01-30 22:35               ` Juri Linkov
2020-01-30 23:07                 ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2022-04-09  4:46 emacsq
2022-04-09 18:53 ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tv4dlvqj.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=emacs-devel@gnu.org \
    --cc=emacsuser@freemail.hu \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).