From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Date: Wed, 08 Dec 2021 22:01:14 +0200 Message-ID: <8335n2x3w5.fsf@gnu.org> References: <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> <837dy7e3wr.fsf@gnu.org> <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> <835zdre31u.fsf@gnu.org> <87v9lpluez.fsf@mail.linkov.net> <874koxwi1t.fsf@gnus.org> <86pmqa51cz.fsf@mail.linkov.net> <87bl1uojxd.fsf@gnus.org> <86czmakaem.fsf@mail.linkov.net> <87tufmnuz6.fsf@gnus.org> <86bl1uyt8f.fsf@mail.linkov.net> <87r1aocf5p.fsf@gnus.org> <83czm7xozh.fsf@gnu.org> <86wnkerjgt.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5405"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 08 21:02:19 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mv38s-0001F3-8F for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Dec 2021 21:02:18 +0100 Original-Received: from localhost ([::1]:42866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv38r-0002Qo-6q for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Dec 2021 15:02:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv38g-0002Pj-8X for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:02:09 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58168) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mv38c-0000fa-5q for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:02:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mv38c-0005A9-3m for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Dec 2021 20:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs Original-Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163899370019789 (code B ref 40774); Wed, 08 Dec 2021 20:02:02 +0000 Original-Received: (at 40774) by debbugs.gnu.org; 8 Dec 2021 20:01:40 +0000 Original-Received: from localhost ([127.0.0.1]:41471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv38F-000596-Vf for submit@debbugs.gnu.org; Wed, 08 Dec 2021 15:01:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv38E-00058t-Dm for 40774@debbugs.gnu.org; Wed, 08 Dec 2021 15:01:39 -0500 Original-Received: from [2001:470:142:3::e] (port=43936 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv389-0000bR-1b; Wed, 08 Dec 2021 15:01:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=eWoI7tX/EFdwaaK2TkmPEWCx5Hwj0A5K7Fw67HNhXBk=; b=moMNTEkPPEkE tMU55gG/2vWTXtPrAnuJcSAN060woofZYNzad4tA2FYdBzb9H5v8Yy58nc2/hqyI++KlvLcBTrfR6 zZKjTvE7SpznZXOWm/hqKHbWKwPL4POJBKYFNLlAqd3ZMw4VIsOg4zntd5zAt3iwDqGwGvA5HdR3+ ZXUTBx1Yay6ceZ6x7hSNdq4gGr/8omwWbKy+XcJiL4+j8SFNsAnTwxHzQ4aD1DBmZ+W9O5ySvMcpQ LDJzBuknCWAc6TcRpZVWdwP5eo15cXkpHEgCoNnj1PUtORt0Gq5zm9xLKY1z4JdWsQxLV+6fSChaH 2ywERrFTI1OCwparXxoNyg==; Original-Received: from [87.69.77.57] (port=3302 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv388-0002tW-Pf; Wed, 08 Dec 2021 15:01:33 -0500 In-Reply-To: <86wnkerjgt.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 08 Dec 2021 21:21:22 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:221946 Archived-At: > From: Juri Linkov > Cc: Lars Ingebrigtsen , 40774@debbugs.gnu.org, > ndame@protonmail.com > Date: Wed, 08 Dec 2021 21:21:22 +0200 > > +** The return value of 'clear-message-function' is not ignored anymore. > +If the function returns t, then the message is not cleared, > +with the assumption that the function cleared it itself. I could perhaps agree to this if the special new behavior was the result of a very special return value, and only that value. Having the new behavior kick in for t is out of the question for the release branch, as it is highly likely to trip unsuspecting Lisp programs. Btw, what does the change of the order between the call of clear-message-function and setting echo_area_buffer[0] to nil mean, compatibility-wise? won't it also produce different results, even if the return value is nil? More generally, I fear that we are trying very hard to tweak a particular infrastructure for a job for which it was hardly meant. IOW, shouldn't we provide some completely different optional feature for this use case? Like a special buffer that pops up or a special frame? Echo-area is not suited for showing large chunks of text, and my gut feeling is that we will bump into problems on this path. E.g., what happens when there are enough accumulated messages that they can no longer be shown with the maximum allowed height of the mini-window?