From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Intelligent stacking of messages in the echo area Date: Thu, 30 Jan 2020 00:54:12 +0200 Organization: LINKOV.NET Message-ID: <87tv4dlvqj.fsf@mail.linkov.net> References: <87sgldfi9j.fsf@mail.linkov.net> <878sn3g0o7.fsf@gmail.com> <87pngepti3.fsf@mail.linkov.net> <87mubidptp.fsf@localhost> <875zi5ntts.fsf@mail.linkov.net> <87blrxdl2w.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="3105"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.60 (x86_64-pc-linux-gnu) Cc: ndame , "emacs-devel@gnu.org" To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 30 00:45:50 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iwx1q-0000lE-8f for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Jan 2020 00:45:50 +0100 Original-Received: from localhost ([::1]:53058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iwx1p-0003wB-7i for ged-emacs-devel@m.gmane-mx.org; Wed, 29 Jan 2020 18:45:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40520) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iwx0W-0002Zj-L5 for emacs-devel@gnu.org; Wed, 29 Jan 2020 18:44:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iwx0V-0003Rm-EA for emacs-devel@gnu.org; Wed, 29 Jan 2020 18:44:28 -0500 Original-Received: from crocodile.birch.relay.mailchannels.net ([23.83.209.45]:50055) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iwx0U-0003Ok-KX for emacs-devel@gnu.org; Wed, 29 Jan 2020 18:44:27 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 107B1580E55; Wed, 29 Jan 2020 23:44:25 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a85.g.dreamhost.com (100-96-86-194.trex.outbound.svc.cluster.local [100.96.86.194]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7EFEE58024A; Wed, 29 Jan 2020 23:44:24 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a85.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Wed, 29 Jan 2020 23:44:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Occur-Zesty: 4aed5f0e08308c28_1580341464865_2915590257 X-MC-Loop-Signature: 1580341464865:2095985611 X-MC-Ingress-Time: 1580341464865 Original-Received: from pdx1-sub0-mail-a85.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTP id 487EA7F012; Wed, 29 Jan 2020 15:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=4W18ZBLs7Km7TtsXOJYK/Tl/nE0=; b= uYUnbzPy6WCq7wPCyraj8U2iOIlrpLcKqgriFEsOEyyDdqltLgGj1LIl/cjDGGnt /SXQm5cTtiUlbu7Htq4Uz6z1bODyHMjLTbY/v+zl33XBi7LP/qshuZe3g3vb429+ SpElTcgoQGHRN3pPD6o4yCfuEXrH4xGFyIFZJf28BQU= Original-Received: from mail.jurta.org (m91-129-105-126.cust.tele2.ee [91.129.105.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 9F06F7F00E; Wed, 29 Jan 2020 15:44:17 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a85 In-Reply-To: <87blrxdl2w.fsf@localhost> (Ihor Radchenko's message of "Wed, 25 Dec 2019 13:35:03 +0800") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrfeejgdduudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrddutdehrdduvdeinecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrddutdehrdduvdeipdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohephigrnhhtrghrledvsehgmhgrihhlrdgtohhm X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 23.83.209.45 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244757 Archived-At: >> 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)