From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Intelligent stacking of messages in the echo area Date: Wed, 25 Dec 2019 13:35:03 +0800 Message-ID: <87blrxdl2w.fsf@localhost> References: <87sgldfi9j.fsf@mail.linkov.net> <878sn3g0o7.fsf@gmail.com> <87pngepti3.fsf@mail.linkov.net> <87mubidptp.fsf@localhost> <875zi5ntts.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="139686"; mail-complaints-to="usenet@blaine.gmane.org" Cc: ndame , "emacs-devel@gnu.org" To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 25 06:37:46 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ijzMf-000aDG-Le for ged-emacs-devel@m.gmane.org; Wed, 25 Dec 2019 06:37:45 +0100 Original-Received: from localhost ([::1]:44062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijzMd-0006Ib-FT for ged-emacs-devel@m.gmane.org; Wed, 25 Dec 2019 00:37:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33773) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijzM9-0005sG-Uz for emacs-devel@gnu.org; Wed, 25 Dec 2019 00:37:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ijzM6-00081k-CN for emacs-devel@gnu.org; Wed, 25 Dec 2019 00:37:11 -0500 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:42513) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ijzM5-000819-ON for emacs-devel@gnu.org; Wed, 25 Dec 2019 00:37:10 -0500 Original-Received: by mail-wr1-x430.google.com with SMTP id q6so21144954wro.9 for ; Tue, 24 Dec 2019 21:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=hB+SkHwQmAb6wWQsqcva6PbGSAv+XZ6fY/k2cVE3qCo=; b=dDUmmAjoq/9jLpobqS5wluEyOD7W95+8U7BiG68GTtQ31QPL+qLhjIB46QjyVHT8K0 zRTnlqEyTYXE+BI57Sz1jaiKYLouDS3eMPamUKy2Tp+aVYqJ3FtdCQWCddgjDYpj4IG5 Aw32BDQwjEk81KMs8EFY/3FPHbZYCh95ZmFqKLWGvAPyB6MJMHLo3JHl8OzXeylrDku6 8FSaxyx6wfgW4IG2kiIvBBh1nMHMb1yP48827EVshods8xgHgo1ZFu/OyHcXG2XZv25v j4ZQB4NeNgp0EDZNu4gbT56wVZFB2EEcjz57E32u4c0DnHl9pN/1pnmPiTZFdEgAI8xm LppQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=hB+SkHwQmAb6wWQsqcva6PbGSAv+XZ6fY/k2cVE3qCo=; b=ctxpi/l+pn6wfKJ8G6fiBxhhh2Xzxt2cVErJD7tWSvdJXOAM6yrEEujE+xe47F/f8w IWscL3314lDLpKV87EjRQapiETIxXMWHcXAcWRs6g3jIhaTWKnJ5M2neYQ3X4L8B7F9e 7al5mDCS5BGDcI2t5RYIRuDpoQl1/AZYydfV1zI9ExSPvVqbWrWgiiKxjX+ju8Kjkwd3 URyIzmJORwuKzWdDwflmVGMCHkJcf2S6d410VXaH/OLgz8yl+GGd4wbm8B2KNKc3Mo9c HBhRjMQiFW2Ds8DwRp18QjWCoBxYF6RfY9DOOiTNSxPGacRPmUk+mSmS6p2EgkuPOLN4 G9DQ== X-Gm-Message-State: APjAAAUltRYWA3iirtDTDlyNyx29bvMSNUi9uHCMgU2B+psk+zMutjwb ENtUGjJ2q89Nwn6Ujkvis+g= X-Google-Smtp-Source: APXvYqx51jIkVFhAK6LnrjN5Min3KBRH9kny3/HQ8bbg2obsPLYufIAQu9HvANGK1vKMM+jVHIopOg== X-Received: by 2002:adf:e5cf:: with SMTP id a15mr21674374wrn.140.1577252228572; Tue, 24 Dec 2019 21:37:08 -0800 (PST) Original-Received: from localhost ([5.226.137.4]) by smtp.gmail.com with ESMTPSA id v83sm4703860wmg.16.2019.12.24.21.37.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Dec 2019 21:37:07 -0800 (PST) In-Reply-To: <875zi5ntts.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::430 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243625 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. Best, Ihor > Now for the multi-message feature where multi-line messages are > not an exception but a rule, one way to mitigate it is to use > a message separator other than a newline, e.g. > > (setq multi-message-separator (propertize ";" 'face 'minibuffer-prompt)) > > In a wide frame, one echo-area line can accommodate several short messages > without resizing the echo-area window. This is a workaround, not a solution. Also, I am using a laptop with small screen and this workaround does not really work for me (at least for org-capture, which emits fairly long messages). Juri Linkov writes: >> I was testing the code for a while. >> There seem to be one irritating (for me) problem with the way >> set-message-function is implemented. >> When I run a command changing current buffer and emitting multiple >> messages, emacs frame is redrawn every time a new message comes out. >> Specifically, I was running org-capture, which changes windows >> configuration, switches to different buffer, and emits multiple messages >> while running. Normally, it runs very fast (the capture template I used >> does not require any user input), but with multi-message, I can see the >> frame being redrawn on every new message popping up. Since window >> configuration is different, full redraw is forced and the whole >> org-capture runs a lot slower. > > 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. > > It seems the same problem existed for a long time, but had no noticeable effect > because multi-line messages were rare. > > Now for the multi-message feature where multi-line messages are > not an exception but a rule, one way to mitigate it is to use > a message separator other than a newline, e.g. > > (setq multi-message-separator (propertize ";" 'face 'minibuffer-prompt)) > > In a wide frame, one echo-area line can accommodate several short messages > without resizing the echo-area window. -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg