From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 16:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 40774@debbugs.gnu.org X-Debbugs-Original-To: "bug-gnu-emacs@gnu.org" Reply-To: ndame Received: via spool by submit@debbugs.gnu.org id=B.158757252328818 (code B ref -1); Wed, 22 Apr 2020 16:23:01 +0000 Received: (at submit) by debbugs.gnu.org; 22 Apr 2020 16:22:03 +0000 Received: from localhost ([127.0.0.1]:53033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRI8R-0007Uj-6o for submit@debbugs.gnu.org; Wed, 22 Apr 2020 12:22:03 -0400 Received: from lists.gnu.org ([209.51.188.17]:35226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRI8P-0007UH-AY for submit@debbugs.gnu.org; Wed, 22 Apr 2020 12:22:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34498) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRI8M-0004Tk-N7 for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:22:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRI8L-0001yP-KX for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:21:58 -0400 Received: from mail-40135.protonmail.ch ([185.70.40.135]:11037) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRI8K-0001G5-05 for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:21:57 -0400 Date: Wed, 22 Apr 2020 16:21:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587572508; bh=3uBpupDUpcB6b59DbBGK58F5r41YrgV69T4WWtSDQ7k=; h=Date:To:From:Reply-To:Subject:From; b=lB5Sy73WODc4N/XaRwMVC9rc64/Gi+1f+g4z+AvvMvx2kiOBcXSGny8jgu1JIDtyv TLhwsi81MLsOaYMJB1qk0aL6Lb0NYqo6B9/zr8U4Rk5+XnP6EcQafFu9QhRzrrYcuv qgkudfWrTSBGAU+Y/3CtpHll7qLXRudknmanSwQw= From: ndame Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_b8419a4c37e61ac77fb2191a78453309" Received-SPF: pass client-ip=185.70.40.135; envelope-from=ndame@protonmail.com; helo=mail-40135.protonmail.ch X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/22 12:21:49 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.70.40.135 X-Spam-Score: 2.3 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: If a message is printed in the echo area then it can be hidden in two ways: either the user uses some command and the echo area is cleared automatically or an other message comes which replaces the pr [...] Content analysis details: (2.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: protonmail.com] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [209.51.188.17 listed in list.dnswl.org] 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ndame[at]protonmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 HTML_MESSAGE BODY: HTML included in message 2.0 SPOOFED_FREEMAIL No description available. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --b1_b8419a4c37e61ac77fb2191a78453309 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SWYgYSBtZXNzYWdlIGlzIHByaW50ZWQgaW4gdGhlIGVjaG8gYXJlYSB0aGVuIGl0IGNhbiBiZSBo aWRkZW4gaW4gdHdvCndheXM6IGVpdGhlciB0aGUgdXNlciB1c2VzIHNvbWUgY29tbWFuZCBhbmQg dGhlIGVjaG8gYXJlYSBpcyBjbGVhcmVkCmF1dG9tYXRpY2FsbHkgb3IgYW4gb3RoZXIgbWVzc2Fn ZSBjb21lcyB3aGljaCByZXBsYWNlcyB0aGUgcHJldmlvdXMKb25lLgoKSSB1c2Ugc2V2ZXJhbCB0 aW1lcnMgd2hpY2ggcGVyZm9ybSByZWN1cnJpbmcgb3IgYmFja2dyb3VuZCB0YXNrcywKZS5nLiBm ZXRjaGluZyB0aGluZ3MgZnJvbSB0aGUgbmV0d29yay4gV2hlbiB0aGVyZSBpcyBhbiBlcnJvciBp biBzdWNoCmEgdGltZXIgdGhlbiBvZnRlbiBJIG9ubHkga25vdyBhYm91dCBpdCBieSBub3RpY2lu ZyB0aGF0IHRoZSB0YXNrIGRvZXMKbm90IHByb2R1Y2UgdGhlIHVzdWFsIHJlc3VsdHMsIGUuZy4g ZmFpbHMgdG8gdXBkYXRlIHNvbWV0aGluZywgYmVjYXVzZQpvdGhlciBwcm9ncmVzcyBtZXNzYWdl cyBoaWRlIHRoZSBwcmludGVkIGVycm9ycy4KCkEgYmV0dGVyIHdheSBjYW4gYmUgaWYgZXJyb3Ig bWVzc2FnZXMgY2FuJ3QgYmUgaGlkZGVuIGlmIHRoZSB1c2VyIGlzCmlkbGUuIFdoZW4gSSdtIHVz aW5nIGVtYWNzIHRoZW4gSSB1c3VhbGx5IG5vdGljZSB0aGUgZXJyb3IsIGJ1dCBpZiBJJ20KaW4g YW4gb3RoZXIgYXBwIGFuZCB0aGUgZXJyb3Igb2NjdXJzIGluIHRoZSBtZWFudGltZSB0aGVuIG9m dGVuIGl0J3MKaGlkZGVuIGJ5IGEgcHJvZ3Jlc3MgbWVzc2FnZSBieSB0aGUgdGltZSBJIHN3aXRj aCBiYWNrIHRvIGVtYWNzLgoKU28gd2hlbiB0aGUgdXNlciBpcyBub3QgaWRsZSB0aGVuIHRoaW5n cyBzaG91bGQgd29yayBhcyB0b2RheS4gQnV0IGlmCnRoZSB1c2VyIGlzIGlkbGUgKGUuZy4gdXNl cyBhbiBvdGhlciBhcHAgb3IgaXMgYXdheSBmcm9tIHRoZSBjb21wdXRlcikKdGhlbiBlcnJvciBt ZXNzYWdlcyBzaG91bGQgbm90IGJlIGhpZGRlbiBieSBvdGhlciBtZXNzYWdlcywgcmF0aGVyCnRo ZXkgc2hvdWxkIGFsbCBiZSBzaG93biBpbiBhIG11bHRpbGluZSBlY2hvIGFyZWEsIHNvIHdoZW4g dGhlIHVzZXIKZ2V0cyBiYWNrIHRvIGVtYWNzIGhlIGNhbiBzZWUgYWxsIHRoZSBlcnJvcnMgd2hp Y2ggaGFwcGVuZWQgd2hpbGUgaGUKd2FzIGF3YXku --b1_b8419a4c37e61ac77fb2191a78453309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JZiBhIG1lc3NhZ2UgaXMgcHJpbnRlZCBpbiB0aGUgZWNobyBhcmVhIHRoZW4gaXQgY2Fu IGJlIGhpZGRlbiBpbiB0d288YnI+PC9kaXY+PGRpdj53YXlzOiBlaXRoZXIgdGhlIHVzZXIgdXNl cyBzb21lIGNvbW1hbmQgYW5kIHRoZSBlY2hvIGFyZWEgaXMgY2xlYXJlZDxicj48L2Rpdj48ZGl2 PmF1dG9tYXRpY2FsbHkgb3IgYW4gb3RoZXIgbWVzc2FnZSBjb21lcyB3aGljaCByZXBsYWNlcyB0 aGUgcHJldmlvdXM8YnI+PC9kaXY+PGRpdj5vbmUuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+SSB1c2Ugc2V2ZXJhbCB0aW1lcnMgd2hpY2ggcGVyZm9ybSByZWN1cnJpbmcgb3IgYmFja2dy b3VuZCB0YXNrcyw8YnI+PC9kaXY+PGRpdj5lLmcuIGZldGNoaW5nIHRoaW5ncyBmcm9tIHRoZSBu ZXR3b3JrLiBXaGVuIHRoZXJlIGlzIGFuIGVycm9yIGluIHN1Y2g8YnI+PC9kaXY+PGRpdj5hIHRp bWVyIHRoZW4gb2Z0ZW4gSSBvbmx5IGtub3cgYWJvdXQgaXQgYnkgbm90aWNpbmcgdGhhdCB0aGUg dGFzayBkb2VzPGJyPjwvZGl2PjxkaXY+bm90IHByb2R1Y2UgdGhlIHVzdWFsIHJlc3VsdHMsIGUu Zy4gZmFpbHMgdG8gdXBkYXRlIHNvbWV0aGluZywgYmVjYXVzZTxicj48L2Rpdj48ZGl2Pm90aGVy IHByb2dyZXNzIG1lc3NhZ2VzIGhpZGUgdGhlIHByaW50ZWQgZXJyb3JzLjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PkEgYmV0dGVyIHdheSBjYW4gYmUgaWYgZXJyb3IgbWVzc2FnZXMgY2Fu J3QgYmUgaGlkZGVuIGlmIHRoZSB1c2VyIGlzPGJyPjwvZGl2PjxkaXY+aWRsZS4gV2hlbiBJJ20g dXNpbmcgZW1hY3MgdGhlbiBJIHVzdWFsbHkgbm90aWNlIHRoZSBlcnJvciwgYnV0IGlmIEknbTxi cj48L2Rpdj48ZGl2PmluIGFuIG90aGVyIGFwcCBhbmQgdGhlIGVycm9yIG9jY3VycyBpbiB0aGUg bWVhbnRpbWUgdGhlbiBvZnRlbiBpdCdzPGJyPjwvZGl2PjxkaXY+aGlkZGVuIGJ5IGEgcHJvZ3Jl c3MgbWVzc2FnZSBieSB0aGUgdGltZSBJIHN3aXRjaCBiYWNrIHRvIGVtYWNzLjxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PlNvIHdoZW4gdGhlIHVzZXIgaXMgbm90IGlkbGUgdGhlbiB0aGlu Z3Mgc2hvdWxkIHdvcmsgYXMgdG9kYXkuIEJ1dCBpZjxicj48L2Rpdj48ZGl2PnRoZSB1c2VyIGlz IGlkbGUgKGUuZy4gdXNlcyBhbiBvdGhlciBhcHAgb3IgaXMgYXdheSBmcm9tIHRoZSBjb21wdXRl cik8YnI+PC9kaXY+PGRpdj50aGVuIGVycm9yIG1lc3NhZ2VzIHNob3VsZCBub3QgYmUgaGlkZGVu IGJ5IG90aGVyIG1lc3NhZ2VzLCByYXRoZXI8YnI+PC9kaXY+PGRpdj50aGV5IHNob3VsZCBhbGwg YmUgc2hvd24gaW4gYSBtdWx0aWxpbmUgZWNobyBhcmVhLCBzbyB3aGVuIHRoZSB1c2VyPGJyPjwv ZGl2PjxkaXY+Z2V0cyBiYWNrIHRvIGVtYWNzIGhlIGNhbiBzZWUgYWxsIHRoZSBlcnJvcnMgd2hp Y2ggaGFwcGVuZWQgd2hpbGUgaGU8YnI+PC9kaXY+PGRpdj53YXMgYXdheS48YnI+PC9kaXY+ --b1_b8419a4c37e61ac77fb2191a78453309-- From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 16:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame , 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158757287929378 (code B ref 40774); Wed, 22 Apr 2020 16:28:01 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 16:27:59 +0000 Received: from localhost ([127.0.0.1]:53042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRIEB-0007dl-EO for submit@debbugs.gnu.org; Wed, 22 Apr 2020 12:27:59 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:38600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRIEA-0007dY-GN for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 12:27:59 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03MGIfTk151268; Wed, 22 Apr 2020 16:27:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=Vd+k0p58BQwt5i25lxASE8cdmYUCN2MO4dNjSIRDWWU=; b=LSSp5jrFOEihFGnOgHAI8bxPmVm67697OQdOa3a2R5NPTCW4Kgm7CoToi54OWyD/4Aq7 zYYZzhePTHEPLb1fbOvkTiCrquPGyn3rmhb1uXGlj/yUJWGq374YSGsY04TWnR87Xh38 7TBzW8MC365YOqH5eaet+tPyN+HdTrpkA9iGS7LNdAznYPJUDf0FNX8/pAVpuLNdSYHv 9F/v08ykoz9Z4qgltkkE2gKKVssPZzZxrHBq05++RF6O2vVh8EH47RkF6xFDGuM/cwZv kDgmHZOK6il5kbZMMZrczAJBwPGi/7+TLeFOJ8posHGE/opPIFNauvbj/7X+4926KEHf MQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 30grpgrcd5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 16:27:52 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03MGCJDl187943; Wed, 22 Apr 2020 16:27:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 30gb1jwf72-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 16:27:51 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03MGRnHR008020; Wed, 22 Apr 2020 16:27:49 GMT MIME-Version: 1.0 Message-ID: <868b0762-2179-4206-9684-1b944affbbfe@default> Date: Wed, 22 Apr 2020 09:27:48 -0700 (PDT) From: Drew Adams References: In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9599 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220123 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9599 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 bulkscore=0 clxscore=1011 malwarescore=0 phishscore=0 spamscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220123 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > If a message is printed in the echo area then it can be hidden in two way= s: either the user uses some command and the echo area is cleared automatic= ally or an other message comes which replaces the previous one. > I use several timers which perform recurring or background tasks, e.g. fe= tching things from the network. When there is an error in such a timer then= often I only know about it by noticing that the task does not produce the = usual results, e.g. fails to update something, because other progress messa= ges hide the printed errors. > A better way can be if error messages can't be hidden if the user is idle= . When I'm using emacs then I usually notice the error, but if I'm in an ot= her app and the error occurs in the meantime then often it's hidden by a pr= ogress message by the time I switch back to emacs. > So when the user is not idle then things should work as today. But if the= user is idle (e.g. uses an other app or is away from the computer) then er= ror messages should not be hidden by other messages, rather they should all= be shown in a multiline echo area, so when the user gets back to emacs he = can see all the errors which happened while he was away. My suggestion would instead be this: As an _option_ (i.e. one can easily turn it off), have buffer `*Messages*' = be displayed on an idle timer. You can do this yourself, now, BTW. But it might be good for Emacs to offe= r this out of the box. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 16:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158757349330437 (code B ref 40774); Wed, 22 Apr 2020 16:39:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 16:38:13 +0000 Received: from localhost ([127.0.0.1]:53062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRIO5-0007ur-Jz for submit@debbugs.gnu.org; Wed, 22 Apr 2020 12:38:13 -0400 Received: from mail-40135.protonmail.ch ([185.70.40.135]:13080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRIO3-0007ud-5p for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 12:38:12 -0400 Date: Wed, 22 Apr 2020 16:38:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587573484; bh=vL0Xzf5UQrNet+ypwAaPwpG4PKAJf7nxNhDiL4taNdY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=fPSeVz28/z3giC6ugEt0SA3A9Rrc6KLhYIhOv9JTrYq7rFgGxcq+jX/kXWgj0NnF9 7A0qiNDh7Ey6qsmXLZhwFJRfHK8aE9/1XniSnpHp7h/csCOOJ6GiX6djrY2OCWuJqk WpFuQWMgFe/ipe1PqUulnEA42bSUuEFlDQ0fi6GE= From: ndame Message-ID: In-Reply-To: <868b0762-2179-4206-9684-1b944affbbfe@default> References: <868b0762-2179-4206-9684-1b944affbbfe@default> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > My suggestion would instead be this: > > As an option (i.e. one can easily turn it off), have buffer `Messages' be= displayed on an idle timer. This is not the same, because if there are progress messages too then error= s can be drowned in the noise, the user may not notice the error, and the use= r usually doesn't care about progress message history. It's much better if emacs collects the errors while the user is away and sh= ows them when the user is back, because if the computer can collect these then = it should do it instead of the user. And when the user is back and sees the errors then he knows about them righ= t away without having to parse the Messages buffer visually. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 16:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame , ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158757391431075 (code B ref 40774); Wed, 22 Apr 2020 16:46:01 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 16:45:14 +0000 Received: from localhost ([127.0.0.1]:53066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRIUs-000859-BW for submit@debbugs.gnu.org; Wed, 22 Apr 2020 12:45:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRIUq-00084w-5w for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 12:45:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33142) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRIUk-0002iV-9t; Wed, 22 Apr 2020 12:45:06 -0400 Received: from [176.228.60.248] (port=4046 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jRIUj-0008O5-Kg; Wed, 22 Apr 2020 12:45:06 -0400 Date: Wed, 22 Apr 2020 19:44:47 +0300 Message-Id: <83mu73eagw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Date: Wed, 22 Apr 2020 16:21:38 +0000 > From: ndame via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > If a message is printed in the echo area then it can be hidden in two > ways: either the user uses some command and the echo area is cleared > automatically or an other message comes which replaces the previous > one. > > I use several timers which perform recurring or background tasks, > e.g. fetching things from the network. When there is an error in such > a timer then often I only know about it by noticing that the task does > not produce the usual results, e.g. fails to update something, because > other progress messages hide the printed errors. That's why we have the *Messages* buffer, where all the messages are logged, even those that aren't shown in the echo area. A simple solution to your use case is to have the *Messages* buffer shown in a window at all times. > So when the user is not idle then things should work as today. But if > the user is idle (e.g. uses an other app or is away from the computer) > then error messages should not be hidden by other messages, rather > they should all be shown in a multiline echo area, so when the user > gets back to emacs he can see all the errors which happened while he > was away. How do you define "user is idle"? is that only keyboard input, or does that include other kinds of input as well? On a modern graphical system, it isn't trivial to decide whether the user is idle, because there are input events that come from the system, not just from the user making keyboard or mouse gestures. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 17:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875754381017 (code B ref 40774); Wed, 22 Apr 2020 17:11:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 17:10:38 +0000 Received: from localhost ([127.0.0.1]:53075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRItR-0000GK-Kd for submit@debbugs.gnu.org; Wed, 22 Apr 2020 13:10:37 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:49762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRItQ-0000G7-7V for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 13:10:37 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03MH8nBL004743; Wed, 22 Apr 2020 17:10:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=N2Q9tcHuDUz9PrWDv4tpF8CcjgrNa4CAQuFXylUmzqQ=; b=pBFxE8WOYXHXiMAhLhVHm8xeuM+mfHrtnseu9ZGPPdUq9gWV+0irMJ1G89X99hTqPpW3 bATCNDrfZuFWe/2tyGWFsDfntzMGo9vPPQDy1n5Fi+Ufno0gh1eexhtISsRbPhdS+xT7 ERRwFMk/Y5a8/LRvEs38KRR4nXOqgCE9cQABALTxZ6b7GTuOu/lZS5XPrU22FoXMYIh4 4P7XcRkyUzYcIE2sfIAFGlFMq/bqqhwJJI3elH/+pU/EpiMpqgYb0i+d6Ax8TJw9z9FW M20xC1Sus6kda/8+vTHZ5E8Nq/17a/u6BPcKPiiWqjNGWtSBTrfCdGtRrrobyASvdfF5 sw== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 30jhyc2yg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 17:10:30 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03MH7koq098410; Wed, 22 Apr 2020 17:08:30 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 30gb932q6u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Apr 2020 17:08:30 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 03MH8Th6029271; Wed, 22 Apr 2020 17:08:29 GMT MIME-Version: 1.0 Message-ID: Date: Wed, 22 Apr 2020 10:08:28 -0700 (PDT) From: Drew Adams References: <868b0762-2179-4206-9684-1b944affbbfe@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9599 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220129 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9599 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 mlxscore=0 clxscore=1015 suspectscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004220129 X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > My suggestion would instead be this: As an option, > > have buffer `Messages' be displayed on an idle timer. >=20 > This is not the same, because if there are progress messages too then err= ors can be drowned in the noise, the user may not notice the error, and the= user usually doesn't care about progress message history. >=20 > It's much better if emacs collects the errors while the user is away and = shows > them when the user is back, because if the computer can collect these the= n it should do it instead of the user. >=20 > And when the user is back and sees the errors then he knows about them ri= ght away without having to parse the Messages buffer visually. The same trivial messages that pollute *Messages* would pollute your multi-= line echo area. Showing *Messages* has the same effect of showing your multi-line echo area= , no? Except that it's not transient. Emacs "collects the errors while the user is away, and shows them when the = user is back" is exactly what *Messages* does. Even now, even without popping up Messages automatically after some idle pe= riod, you can just click `mouse-1' in the echo area to pop it up. Or use `= C-h e' to do the same thing. (See also: https://stackoverflow.com/q/4682033/729907.) ___ BTW, I wonder if buffer *Messages* shouldn't have a menu-bar menu, with a f= ew items that do things like filter temporarily in various ways, change `me= ssage-log-max', etc. Some things a user might want to do with the buffer c= ontent aren't necessarily obvious. IOW, *Messages* could probably be made more directly useful than it is now. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 17:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875769783635 (code B ref 40774); Wed, 22 Apr 2020 17:37:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 17:36:18 +0000 Received: from localhost ([127.0.0.1]:53130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJII-0000wY-Ac for submit@debbugs.gnu.org; Wed, 22 Apr 2020 13:36:18 -0400 Received: from mail-40130.protonmail.ch ([185.70.40.130]:31687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJIG-0000wK-Bf for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 13:36:17 -0400 Date: Wed, 22 Apr 2020 17:35:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587576969; bh=zY+abVGlu0SA3IX0y6WAo13qAITXL8UD1YvEIe6WtWA=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=ZdV7qzVauk8fo5I2cPu8HGrs4moZhc8n10AnsG32X3IQ+zP/rsQID26+me6BUxx04 Vt50Fxjc6Df4Ucvva7M+C9qHqQn/4o39l2nBr4e9dWFqLL4SnGeqxyqpvJLlMoHG+B ND6n+tBWNewywn3LwNtHsOrhN7tPj6ECsnM8OpDU= From: ndame Message-ID: <63lpk2GC7sBy4iVVqUQnnJdX9_H5z36LByJe_C5e8ttbLOUPMpba6jzLW8IMRdLeAKHK2styHbQml5exispWAnHR5gWysqhbA7R0YUlcntk=@protonmail.com> In-Reply-To: References: <868b0762-2179-4206-9684-1b944affbbfe@default> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > The same trivial messages that polluteMessages would pollute your multi-l= ine echo area. > No, because the echo are in the idle case would show only the actual error = messages, not the trivial progress messages. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 17:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875771363904 (code B ref 40774); Wed, 22 Apr 2020 17:39:01 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 17:38:56 +0000 Received: from localhost ([127.0.0.1]:53148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJKq-00010u-DX for submit@debbugs.gnu.org; Wed, 22 Apr 2020 13:38:56 -0400 Received: from mail-40132.protonmail.ch ([185.70.40.132]:33340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJKp-00010h-1A for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 13:38:55 -0400 Date: Wed, 22 Apr 2020 17:38:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587577128; bh=poYr0aeKeugcWFGdK1vxwpCwGuxN5H6Dh82MRLUf8Is=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=qG2sMpWybKXb8QQJtLk5/yGuX0YAoYoGfcQNGn9T2z+NJDr8Oiw2K+nyYoLVQTEae hDUZ2hf7l4QMi5XDdoPLZU9rYzygmYTXjI7cXcu89JCkAxzWCnpAzjFnS1sZ0c6leH 37O0wklsS89SBQ+qTfHQmf+EZ445V5wzP6qJt6/w= From: ndame Message-ID: <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> In-Reply-To: <83mu73eagw.fsf@gnu.org> References: <83mu73eagw.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > That's why we have theMessages buffer, where all the messages are > logged, even those that aren't shown in the echo area. A simple > solution to your use case is to have the Messages buffer shown in a > window at all times. I don't have screen real estate to constantly show the Messages buffer and it still has the problem that other messages drown the error messages. But I can solve this problem for myself if needed. I only submitted the idea here, because I felt it could be useful for others too. > > How do you define "user is idle"? The same definition what run-with-idle-timer uses is suitable. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 18:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875791117152 (code B ref 40774); Wed, 22 Apr 2020 18:12:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 18:11:51 +0000 Received: from localhost ([127.0.0.1]:53179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJqh-0001rI-EL for submit@debbugs.gnu.org; Wed, 22 Apr 2020 14:11:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRJqc-0001r2-Rr for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 14:11:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34546) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRJqW-0000OH-Vc; Wed, 22 Apr 2020 14:11:41 -0400 Received: from [176.228.60.248] (port=1360 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jRJqV-0005TA-N7; Wed, 22 Apr 2020 14:11:40 -0400 Date: Wed, 22 Apr 2020 21:11:22 +0300 Message-Id: <83ftcve6gl.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> (message from ndame on Wed, 22 Apr 2020 17:38:47 +0000) References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 22 Apr 2020 17:38:47 +0000 > From: ndame > Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> > > > How do you define "user is idle"? > > The same definition what [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: gnu.org] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [209.51.188.92 listed in list.dnswl.org] 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches everything in local email X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Date: Wed, 22 Apr 2020 17:38:47 +0000 > From: ndame > Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> > > > How do you define "user is idle"? > > The same definition what run-with-idle-timer uses is suitable. Are you sure? That defines when _Emacs_ is idle, which is not the same thing. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 18:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875797238265 (code B ref 40774); Wed, 22 Apr 2020 18:23:01 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 18:22:03 +0000 Received: from localhost ([127.0.0.1]:53200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRK0Y-00029E-S9 for submit@debbugs.gnu.org; Wed, 22 Apr 2020 14:22:03 -0400 Received: from mail4.protonmail.ch ([185.70.40.27]:51575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRK0V-00028i-VN for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 14:22:02 -0400 Date: Wed, 22 Apr 2020 18:21:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587579713; bh=7KDV3NqI+V+QbkM9y8ZVDzthlcP9CRYyA076KkN7BZs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=mJwJMS7aMYRxcpzSz4+tROuld5YiKC9qQRrbkLOFABvX+0yCMYxC90na6oHuIe1as VI6Rlv0AFPulohQPSo4EEbjB3Jw9tVb4lrCyBo5A3nU1l6Mqn2W7JmuhmuztOiiYpX agdDXhJy1LIngD61qzJqhxQVkLHbgcBSwc+Ds7lU= From: ndame Message-ID: In-Reply-To: <83ftcve6gl.fsf@gnu.org> References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Wednesday, April 22, 2020 8:11 PM, Eli Zaretskii wrote: > > > > > How do you define "user is idle"? > > > > The same definition what run-with-idle-timer uses is suitable. > > Are you sure? That defines when Emacs is idle, which is not the > same thing. Yes, I meant "user is idle" from Emacs' point of view. I should have been more precise. I wrote: "the user is idle (e.g. uses an other app or is away from the computer)". So this feature comes into play when the user is idle in Emacs, e.g. uses an other app, so doesn't look at the Emacs window and can miss error messages. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 18:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875800048690 (code B ref 40774); Wed, 22 Apr 2020 18:27:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 18:26:44 +0000 Received: from localhost ([127.0.0.1]:53205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRK56-0002G5-F2 for submit@debbugs.gnu.org; Wed, 22 Apr 2020 14:26:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRK54-0002Fq-IQ for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 14:26:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34759) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRK4y-0004Up-TI; Wed, 22 Apr 2020 14:26:36 -0400 Received: from [176.228.60.248] (port=2282 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jRK4x-0006zn-Md; Wed, 22 Apr 2020 14:26:36 -0400 Date: Wed, 22 Apr 2020 21:26:19 +0300 Message-Id: <83blnje5ro.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from ndame on Wed, 22 Apr 2020 18:21:48 +0000) References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Date: Wed, 22 Apr 2020 18:21:48 +0000 > From: ndame > Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> > > > > The same definition what run-with-idle-timer uses is suitable. > > > > Are you sure? That defines when Emacs is idle, which is not the > > same thing. > > Yes, I meant "user is idle" from Emacs' point of view. I should have > been more precise. I wrote: "the user is idle (e.g. uses an other app > or is away from the computer)". > > So this feature comes into play when the user is idle in Emacs, > e.g. uses an other app, so doesn't look at the Emacs window > and can miss error messages. What if the user is looking at another application, and Emacs runs a prolonged operation of sorts, for example, indexing some large directory? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 18:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758104118206 (code B ref 40774); Wed, 22 Apr 2020 18:44:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 18:44:01 +0000 Received: from localhost ([127.0.0.1]:53217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKLp-0004jO-AQ for submit@debbugs.gnu.org; Wed, 22 Apr 2020 14:44:01 -0400 Received: from mail-40132.protonmail.ch ([185.70.40.132]:34465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKLn-0004j8-QE for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 14:44:00 -0400 Date: Wed, 22 Apr 2020 18:43:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587581033; bh=NYSyTgM3U+lRVwihJum6a9A9PlgwxAwqWQpw8lYcL7U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=qHhhQ1TiYOYi12/VtiQMnU9BR1mR2G45QgSNwjJ9IXOLNcb7lPrV7nhy1ZXUz0Zqb nk6fhz/yjuQhJkcJkne0ogruOVNggpTTPeZrdqp0qP6WVQ9v/0dzjCHgXqIHxJtazM s1fuqdsFyTRJkbXpZIMwPlaS+atrlg40nrqs6Cf4= From: ndame Message-ID: In-Reply-To: <83blnje5ro.fsf@gnu.org> References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> <83blnje5ro.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > What if the user is looking at another application, and Emacs runs a > prolonged operation of sorts, for example, indexing some large > directory? I don't get what you're getting at. If the prolonged operation does not stop with an error then nothing happens. If the operation stops with an error then the error will be in the echo area when the user switches back to emacs. This feature only comes into play if a message is printed to the echo area, the message is an error message (sent by error, signal, etc.) and the user is idle in emacs. Then the error (or errors) is stored, so if some other progress message arrives when the user is idle then it does not hide the error, it stays in the echo area. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 18:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758127218606 (code B ref 40774); Wed, 22 Apr 2020 18:48:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 18:47:52 +0000 Received: from localhost ([127.0.0.1]:53225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKPX-0004q2-Q1 for submit@debbugs.gnu.org; Wed, 22 Apr 2020 14:47:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKPW-0004pq-S2 for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 14:47:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34994) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRKPP-0006ir-Jc; Wed, 22 Apr 2020 14:47:44 -0400 Received: from [176.228.60.248] (port=3558 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jRKPP-000217-1d; Wed, 22 Apr 2020 14:47:43 -0400 Date: Wed, 22 Apr 2020 21:47:25 +0300 Message-Id: <838sine4si.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from ndame on Wed, 22 Apr 2020 18:43:48 +0000) References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> <83blnje5ro.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Date: Wed, 22 Apr 2020 18:43:48 +0000 > From: ndame > Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> > > > > > What if the user is looking at another application, and Emacs runs a > > prolonged operation of sorts, for example, indexing some large > > directory? > > I don't get what you're getting at. You want the Emacs behavior to change depending on whether "the user is idle" or not, right? If the practical implementation of that will be "when Emacs is idle", you might not have the behavior you wanted, because Emacs might _not_ be idle when the user is. I hope this clarifies the point I was trying to make. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 18:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758159519144 (code B ref 40774); Wed, 22 Apr 2020 18:54:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 18:53:15 +0000 Received: from localhost ([127.0.0.1]:53233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKUk-0004yi-Ss for submit@debbugs.gnu.org; Wed, 22 Apr 2020 14:53:15 -0400 Received: from mail-40130.protonmail.ch ([185.70.40.130]:47825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKUj-0004yW-EG for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 14:53:13 -0400 Date: Wed, 22 Apr 2020 18:53:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587581587; bh=U9RhVkyg9ADHqlNwRV1tvexNhohY8YA2LOce7H/osMs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=IzmUZ2mnak5RiB3Jr/L3dQuEk125xXkFaJCCEAuLlUo6N8lSIA8N3hJAaNDgbAbAQ 9hCDlCR90w7muIPSEcn3xXUySqD8GcUcVKYsHS9riMKa0HgsJ9fCoX/28DSVqJ8m9Q Tbt4Y1kravPulEsN7uQtdGKzOzBAmYEJuh7zKNow= From: ndame Message-ID: In-Reply-To: <838sine4si.fsf@gnu.org> References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > You want the Emacs behavior to change depending on whether "the user > is idle" or not, right? If the practical implementation of that will > be "when Emacs is idle", you might not have the behavior you wanted, > because Emacs might not be idle when the user is. If Emacs prints a message then the message function can check if the user is idle using the same condition what run-with-idle-timer uses and if so then it can handle displaying the message in different way. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 19:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758241220559 (code B ref 40774); Wed, 22 Apr 2020 19:07:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 19:06:52 +0000 Received: from localhost ([127.0.0.1]:53245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKhw-0005LX-FU for submit@debbugs.gnu.org; Wed, 22 Apr 2020 15:06:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKhv-0005LG-Es for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 15:06:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35177) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRKhq-0003ex-9B; Wed, 22 Apr 2020 15:06:46 -0400 Received: from [176.228.60.248] (port=4715 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jRKhp-0005Of-Fl; Wed, 22 Apr 2020 15:06:46 -0400 Date: Wed, 22 Apr 2020 22:06:28 +0300 Message-Id: <837dy7e3wr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from ndame on Wed, 22 Apr 2020 18:53:01 +0000) References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Date: Wed, 22 Apr 2020 18:53:01 +0000 > From: ndame > Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> > > > You want the Emacs behavior to change depending on whether "the user > > is idle" or not, right? If the practical implementation of that will > > be "when Emacs is idle", you might not have the behavior you wanted, > > because Emacs might not be idle when the user is. > > If Emacs prints a message then the message function can check if the > user is idle using the same condition what run-with-idle-timer > uses and if so then it can handle displaying the message in different way. But that's exactly the problem I see with your proposed strategy: when Emacs prints a message, it is _never_ idle, by definition. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 19:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758265320975 (code B ref 40774); Wed, 22 Apr 2020 19:11:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 19:10:53 +0000 Received: from localhost ([127.0.0.1]:53254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKlp-0005SF-BU for submit@debbugs.gnu.org; Wed, 22 Apr 2020 15:10:53 -0400 Received: from mail4.protonmail.ch ([185.70.40.27]:52884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKln-0005S0-Ib for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 15:10:52 -0400 Date: Wed, 22 Apr 2020 19:10:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587582645; bh=eAZGdeoV6DLPj+7lYA8crJBS19aZNfOchh3E37Yaun8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=dQtDTiQMANVzE4DSShSMZVHpSp7JJ33QhIY1IAIA9hRSSCYSyfmeYi/7SttsNBiGZ ibv+x6ZOzHK5LrzMm0AP8StOfk2J41Bjy5bwsmSxGgR4i3lRoy05tOEVg0MpzZqIm7 QMH/qznNoGFsNSl0HmMn0JhQVx2FxiNXXLt1iVtM= From: ndame Message-ID: <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> In-Reply-To: <837dy7e3wr.fsf@gnu.org> References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> <837dy7e3wr.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > But that's exactly the problem I see with your proposed strategy: > when Emacs prints a message, it is never idle, by definition. But the condition is not "when Emacs is idle", but "when the user is idle". So Emacs can do some processing, running some timers, printing messages while the user is idle in Emacs, right? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 19:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758353122441 (code B ref 40774); Wed, 22 Apr 2020 19:26:01 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 19:25:31 +0000 Received: from localhost ([127.0.0.1]:53275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKzz-0005pt-6q for submit@debbugs.gnu.org; Wed, 22 Apr 2020 15:25:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRKzx-0005pg-Ia for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 15:25:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35360) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRKzs-0000GD-BG; Wed, 22 Apr 2020 15:25:24 -0400 Received: from [176.228.60.248] (port=1865 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jRKzm-0006en-UH; Wed, 22 Apr 2020 15:25:20 -0400 Date: Wed, 22 Apr 2020 22:25:01 +0300 Message-Id: <835zdre31u.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> (message from ndame on Wed, 22 Apr 2020 19:10:36 +0000) References: <83mu73eagw.fsf@gnu.org> <3HKWEOXkDWKA21dsCFgMgmFIMPR3VwPgNzfTjd7I5Igswu07sfhZaP-td1X4Py66xAD6kDLyLjVmujFkuabkY_S9ZZhgGZwi0IaAV6RS59U=@protonmail.com> <83ftcve6gl.fsf@gnu.org> <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> <837dy7e3wr.fsf@gnu.org> <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Date: Wed, 22 Apr 2020 19:10:36 +0000 > From: ndame > Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> > > > But that's exactly the problem I see with your proposed strategy: > > when Emacs prints a message, it is never idle, by definition. > > But the condition is not "when Emacs is idle", but "when the user > is idle". So Emacs can do some processing, running some timers, > printing messages while the user is idle in Emacs, right? We are going in circles. You want Emacs behave two different ways when it is about to show a message, is that right? So I'm asking how will Emacs determine, at that point, whether "the user is idle". The method Emacs uses to determine when to run the next idle timer will not work, because when Emacs is about to print a message, that method will return false, i.e. tell that the user is not idle. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 19:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158758412923546 (code B ref 40774); Wed, 22 Apr 2020 19:36:02 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 19:35:29 +0000 Received: from localhost ([127.0.0.1]:53312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRL9c-00067i-U1 for submit@debbugs.gnu.org; Wed, 22 Apr 2020 15:35:29 -0400 Received: from mail-40130.protonmail.ch ([185.70.40.130]:47698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRL9b-00067U-BM for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 15:35:27 -0400 Date: Wed, 22 Apr 2020 19:35:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587584121; bh=YmOsDYFSzjw97M5/uLaViuAxLVhWllmXHELbRtlXiY0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=gNacmRyiWrnEgGV+EgsHwL0ML8Vu2H762ziRsOTPnBFnQIabkeq31AmwzBqhAvjQf yOR96l6imdF2jtY6ustvFM3t1taXNa/zuw8QDFuKOxdZCeXZUORywTzbDbvEjzWObB bhDx4h6Wgu7Edr/2vOeECHPEhdh0lKXKuAX2xMiI= From: ndame Message-ID: <6ij_9GTWEr8TvtqlwJ__IgMXMaoo6omri90Awd6CZIzQiU5iE7Z7PPkgfm-yjafUtMR4IvbXyWUDvkCnZrMPH5BCS1LprWRcYw6TF6Mq9AU=@protonmail.com> In-Reply-To: <835zdre31u.fsf@gnu.org> References: <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> <837dy7e3wr.fsf@gnu.org> <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> <835zdre31u.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > The method Emacs uses to > determine when to run the next idle timer will not work, because when > Emacs is about to print a message, that method will return false, > i.e. tell that the user is not idle. OK, I didn't check how idle timers worked I just assumed the same method can be used. Then I guess the time of the last command can be used if it's available. If the user did not invoke any command for a while then we can assume he's idle. And it doesn't really matter if the determination of idleness is not precise, because it only means that errors occuring during this time won't be hidden by regular messages, they stay in the echo area. And anytime the user actually invokes a command the echo area is cleared as it works currently. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 22:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: ndame Cc: 40774@debbugs.gnu.org Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15875932446178 (code B ref 40774); Wed, 22 Apr 2020 22:08:01 +0000 Received: (at 40774) by debbugs.gnu.org; 22 Apr 2020 22:07:24 +0000 Received: from localhost ([127.0.0.1]:53523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRNWe-0001ba-Co for submit@debbugs.gnu.org; Wed, 22 Apr 2020 18:07:24 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:45031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRNWc-0001bM-DQ for 40774@debbugs.gnu.org; Wed, 22 Apr 2020 18:07:23 -0400 X-Originating-IP: 91.129.106.11 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 3625CC0007; Wed, 22 Apr 2020 22:07:14 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET References: Date: Thu, 23 Apr 2020 01:05:42 +0300 In-Reply-To: (ndame via's message of "Wed, 22 Apr 2020 16:21:38 +0000") Message-ID: <874ktbfa6h.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > So when the user is not idle then things should work as today. But if > the user is idle (e.g. uses an other app or is away from the computer) > then error messages should not be hidden by other mes [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: gnu.org] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [217.70.183.198 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches everything in local email X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > So when the user is not idle then things should work as today. But if > the user is idle (e.g. uses an other app or is away from the computer) > then error messages should not be hidden by other messages, rather > they should all be shown in a multiline echo area, so when the user > gets back to emacs he can see all the errors which happened while he > was away. Please try the multiline echo area implemented in https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00646.html From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Apr 2020 04:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158761672310996 (code B ref 40774); Thu, 23 Apr 2020 04:39:02 +0000 Received: (at 40774) by debbugs.gnu.org; 23 Apr 2020 04:38:43 +0000 Received: from localhost ([127.0.0.1]:53792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRTdL-0002rI-7c for submit@debbugs.gnu.org; Thu, 23 Apr 2020 00:38:43 -0400 Received: from mail4.protonmail.ch ([185.70.40.27]:57929) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRTdJ-0002r4-K9 for 40774@debbugs.gnu.org; Thu, 23 Apr 2020 00:38:42 -0400 Date: Thu, 23 Apr 2020 04:38:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587616715; bh=eDmYPjLTTgoZIFvxV+kM6Q9epaqozCqVlTOcJ/fpjhY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Oc9YVT/AJajBoy0fFZVOFBZW7SxmJRDYjEmcviDDequ8pmr9MhjiiNweAebDKoO94 Bk32CTZu6aY8ZQDctZilzXDIVE0XMpQd5MJe3nOZLcPLSgTsCFD9AJBAL3AC2lxMRL dNj6d0/njXLv+tEOJG3gaM68vrgIVIwLS56Bk74I= From: ndame Message-ID: In-Reply-To: <874ktbfa6h.fsf@mail.linkov.net> References: <874ktbfa6h.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > Please try the multiline echo area implemented in > https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00646.html Yes, message stacking is also useful for other reasons. I was the one who suggested that feature in that thread. But message stacking clears the stack after a certain timeout which is different than what I'm suggesting here. With a timeout error messages could be hidden again by some other progress message which arrives later. Keeping error messages while the user is idle means the error messages stay up indefinitely until the user comes back even if he comes back, say, an hour later. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Apr 2020 05:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org> Reply-To: ndame Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.158762149419651 (code B ref 40774); Thu, 23 Apr 2020 05:59:02 +0000 Received: (at 40774) by debbugs.gnu.org; 23 Apr 2020 05:58:14 +0000 Received: from localhost ([127.0.0.1]:53904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRUsH-00056t-TW for submit@debbugs.gnu.org; Thu, 23 Apr 2020 01:58:14 -0400 Received: from mail4.protonmail.ch ([185.70.40.27]:63613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRUsG-00056f-2D for 40774@debbugs.gnu.org; Thu, 23 Apr 2020 01:58:12 -0400 Date: Thu, 23 Apr 2020 05:58:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587621485; bh=5G1OFRQPSbgcQMQ6eCfCdxDCSnpV0yEvGQS57wLmfKk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=q6fvgiUzRCndXjJ6bYq1I6ambNzwFjRMi4pmyVo6ahqkAeX9kGNFceIHqYO0x06tZ +H6csxu0h59ZWxOYN96pyc+MOkmi4Vj1Q4tFSYSC5h57w9y5i2GufhiQsx3P8SJ+Ko 9WsZpdaa5F+APAqFb0TjRmoWkldZTgAJS72WqudU= From: ndame Message-ID: In-Reply-To: <835zdre31u.fsf@gnu.org> References: <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> <837dy7e3wr.fsf@gnu.org> <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> <835zdre31u.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > The method Emacs uses to > determine when to run the next idle timer will not work, It just occurred to me there is no need for idle check at all. The echo area is currently automatically cleared when the user performs a command. Otherwise, a new message can override the echo area. Only the latter needs to be changed, so that a new message does not erase error messages. So if emacs is left alone then arriving error messages are accumulated and shown in a multiline echo area. If a new regular message arrives then it is shown at the bottom of the multiline echo area with the earlier error messages above. And when the user comes back and performs a command then the echo area is cleared as usual. So the only change needed is that error messages can only be cleared from the echo area by the user doing some command. Otherwise they are collected and shown. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Apr 2020 22:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 40774@debbugs.gnu.org Cc: eliz@gnu.org, ndame@protonmail.com X-Debbugs-Original-To: ndame via "Bug reports for GNU Emacs, the Swiss army knife of text editors" X-Debbugs-Original-Cc: "40774@debbugs.gnu.org" <40774@debbugs.gnu.org>, Eli Zaretskii , ndame Received: via spool by submit@debbugs.gnu.org id=B.15876804999213 (code B ref -1); Thu, 23 Apr 2020 22:22:02 +0000 Received: (at submit) by debbugs.gnu.org; 23 Apr 2020 22:21:39 +0000 Received: from localhost ([127.0.0.1]:55966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRkDz-0002OX-3K for submit@debbugs.gnu.org; Thu, 23 Apr 2020 18:21:39 -0400 Received: from lists.gnu.org ([209.51.188.17]:53236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRkDw-0002OO-Vo for submit@debbugs.gnu.org; Thu, 23 Apr 2020 18:21:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60562) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRkDw-0004bB-Gu for bug-gnu-emacs@gnu.org; Thu, 23 Apr 2020 18:21:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRkDq-0001ha-WE for bug-gnu-emacs@gnu.org; Thu, 23 Apr 2020 18:21:35 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:41591) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jRkDq-0001XU-9q; Thu, 23 Apr 2020 18:21:30 -0400 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 13923200006; Thu, 23 Apr 2020 22:21:25 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET References: <83blnje5ro.fsf@gnu.org> <838sine4si.fsf@gnu.org> <837dy7e3wr.fsf@gnu.org> <-ZmNQQ07JD7L0I5EpXolv4t1UhWBGc4SN0dkJml3cLbBjO6ucAMUzAqsI9Ca69xO_hzlMLfaLs6bY9vq8GAR24RUGu1LZqVoVkXhiJcFgtg=@protonmail.com> <835zdre31u.fsf@gnu.org> Date: Fri, 24 Apr 2020 01:16:36 +0300 In-Reply-To: (ndame via's message of "Thu, 23 Apr 2020 05:58:01 +0000") Message-ID: <87v9lpluez.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=217.70.178.232; envelope-from=juri@linkov.net; helo=relay12.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/23 18:21:27 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Received-From: 217.70.178.232 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain > So the only change needed is that error messages can only be cleared > from the echo area by the user doing some command. Otherwise they > are collected and shown. I see now what you mean. This can be easily implemented with the following patch. So you can set `clear-message-function' to a function that returns a non-nil, and the echo area won't be cleared. Such predicate function could contain a complex logic, but for testing you could use just: (setq clear-message-function (lambda () t)) --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=clear_message.patch diff --git a/src/xdisp.c b/src/xdisp.c index 01f272033e..fb9def57ef 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -11825,18 +11825,23 @@ set_message_1 (ptrdiff_t a1, Lisp_Object string) void clear_message (bool current_p, bool last_displayed_p) { + Lisp_Object preserve = Qnil; + if (current_p) { - echo_area_buffer[0] = Qnil; - message_cleared_p = true; - if (FUNCTIONP (Vclear_message_function)) { ptrdiff_t count = SPECPDL_INDEX (); specbind (Qinhibit_quit, Qt); - safe_call (1, Vclear_message_function); + preserve = safe_call (1, Vclear_message_function); unbind_to (count, Qnil); } + + if (NILP (preserve)) + { + echo_area_buffer[0] = Qnil; + message_cleared_p = true; + } } if (last_displayed_p) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 27 10:32:58 2020 Received: (at control) by debbugs.gnu.org; 27 Apr 2020 14:32:58 +0000 Received: from localhost ([127.0.0.1]:37750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT4oc-00089G-Kk for submit@debbugs.gnu.org; Mon, 27 Apr 2020 10:32:58 -0400 Received: from mail-qk1-f179.google.com ([209.85.222.179]:42944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT4ob-000894-I1 for control@debbugs.gnu.org; Mon, 27 Apr 2020 10:32:57 -0400 Received: by mail-qk1-f179.google.com with SMTP id b188so16566701qkd.9 for ; Mon, 27 Apr 2020 07:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=HKPRjIF7AH2Nm8f8mA8XTFw0j9UWvsnXpid8BF2zbC4=; b=pSqUuOIuOphFJeOnppLLG6Z7PXZGhM4cXtVAV+vVnKYC4CA/lHHe+fed4DT3dnejac Vw+wBdpyJ/cjrdwNgRJ+9ueE2d7hREKyTMpY7xm0n/1K3kSY1+IPq0S76fmwG5Lgth8P n+MoN9gRzoB1Qi+zsNw4QH5ogfIxttpHE7bKuoWDkd7XCqFtzn1aIJs0ajOmBT2gRpE/ MMr+vFyLt0m20AfcHX+//BSNtyzhzGJO6IHfadADZ9xYdz2pCdhI6kY9to+VmdcVte3m ED+8YJQNkJ9V1usYUPPKU3XRTWa0Imcx949xp7Mjy0UIeBLqfwcFuE3MtTpWWLoPaybp XQQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=HKPRjIF7AH2Nm8f8mA8XTFw0j9UWvsnXpid8BF2zbC4=; b=OlkL3/ONgwOxvjA5v+GvSp5l3iEEqDGbgvhIhbmSEayVC03qqaigGe7sIwQfylL2ip XaPAbFEyn4J3JoEbSEH8YzIdQzwlmLjmCkbh36TXZqAymZzSSb6h0dwOFIHhitq2vYzL R96DzWmg11ocZ0fCj6GrUJSWMp6lyXAYc3uT2WXTT6uj8KE2oz52GsdkectQfuRuE7Xk kYbEn0uEb22AhhuYapwfFEiM/O0A+Da3Em+aSYVuozyteQjaiU86+WmlYs82Pi9uN4FT 8m4ekRLlu1CAVC1gp+pYNhnTUKFk3zxKLth92Cs8svoomOBGYFQvo5TitgSiUR2mzkqM XSCQ== X-Gm-Message-State: AGi0PuaWru5dMb14Sdvw9c2OJI5Y+LyXhSltGJ+jUulwzChzM/i+DZoJ dX4RekN+CDwQurWOTeD5/IyJ9frC X-Google-Smtp-Source: APiQypIXigqycr3mH+909sNW3ZL0Q1V4kRfgEuxS4A1HCBXVXkQiDENgUr6vmxzezpltrXls0w5iAg== X-Received: by 2002:a05:620a:749:: with SMTP id i9mr23156104qki.408.1587997971714; Mon, 27 Apr 2020 07:32:51 -0700 (PDT) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.38.42]) by smtp.gmail.com with ESMTPSA id 39sm10500697qtg.94.2020.04.27.07.32.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Apr 2020 07:32:51 -0700 (PDT) From: Noam Postavsky To: control@debbugs.gnu.org Subject: control message for bug #40817 Date: Mon, 27 Apr 2020 10:32:49 -0400 Message-ID: <854kt59ey6.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 40817 minor severity 40890 minor severity 40900 wishlist tags 40802 + unreproducible tags 40776 + moreinfo severity 40774 wishlist quit From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Aug 2020 13:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.15979309293263 (code B ref 40774); Thu, 20 Aug 2020 13:43:01 +0000 Received: (at 40774) by debbugs.gnu.org; 20 Aug 2020 13:42:09 +0000 Received: from localhost ([127.0.0.1]:42007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kpV-0000qZ-4N for submit@debbugs.gnu.org; Thu, 20 Aug 2020 09:42:09 -0400 Received: from quimby.gnus.org ([95.216.78.240]:57660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kpR-0000pe-M8 for 40774@debbugs.gnu.org; Thu, 20 Aug 2020 09:42:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GjTEvOge1gvgDhTGNf8jGZHl59Rv+YC6cUWSYiLbypU=; b=R440u3sO0PAE2mv8w+tFu5vNBa aCr8z6H/6Gwav0+zp2rc7osbSD8+NDA5OZ2/oPXOC8ysTeDXsdPSVoHb59Yp0tpjFW5tdumMvEOu7 DFC+eo29Q9u/2QGHcupwSvnx+M7KY9TVgVEObyIzIYWDI1GDYDOk7dFu+EdXDk0E5krg=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8kpE-00040t-4i; Thu, 20 Aug 2020 15:41:54 +0200 From: Lars Ingebrigtsen 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> X-Now-Playing: Various's _SHAPE Platform 2019_: "Maria W Horn - Intelocked Cycles II" Date: Thu, 20 Aug 2020 15:41:50 +0200 In-Reply-To: <87v9lpluez.fsf@mail.linkov.net> (Juri Linkov's message of "Fri, 24 Apr 2020 01:16:36 +0300") Message-ID: <874koxwi1t.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > I see now what you mean. This can be easily implemented with the > following patch. So you can set `clear-message-function' to a function > that returns a non-nil, and the echo area won't be cleared [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Juri Linkov writes: > I see now what you mean. This can be easily implemented with the > following patch. So you can set `clear-message-function' to a function > that returns a non-nil, and the echo area won't be cleared. > > Such predicate function could contain a complex logic, but for testing > you could use just: > > (setq clear-message-function (lambda () t)) [...] > - safe_call (1, Vclear_message_function); > + preserve = safe_call (1, Vclear_message_function); > unbind_to (count, Qnil); > } > + > + if (NILP (preserve)) > + { > + echo_area_buffer[0] = Qnil; > + message_cleared_p = true; > + } It an interesting idea, but I don't think this would be a backwards-compatible implementation. Today, the return value of clear-message-function isn't used, so we have to assume that users of that variable returns... whatever. Giving it semantics now would lead to the message area being preserved unexpectedly. Or not, if somebody has used that function to semi-clear the echo area, and then return nil? So this would have to be implemented in a different way, unfortunately, I think. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Dec 2021 19:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16387315148500 (code B ref 40774); Sun, 05 Dec 2021 19:12:02 +0000 Received: (at 40774) by debbugs.gnu.org; 5 Dec 2021 19:11:54 +0000 Received: from localhost ([127.0.0.1]:59468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtwvS-0002D1-66 for submit@debbugs.gnu.org; Sun, 05 Dec 2021 14:11:54 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:53593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtwvP-0002Ch-Sl for 40774@debbugs.gnu.org; Sun, 05 Dec 2021 14:11:52 -0500 Received: (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 2897120002; Sun, 5 Dec 2021 19:11:43 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET 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> Date: Sun, 05 Dec 2021 20:54:20 +0200 In-Reply-To: <874koxwi1t.fsf@gnus.org> (Lars Ingebrigtsen's message of "Thu, 20 Aug 2020 15:41:50 +0200") Message-ID: <86pmqa51cz.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> + if (NILP (preserve)) >> + { >> + echo_area_buffer[0] = Qnil; >> + message_cleared_p = true; >> + } > > It an interesting idea, but I don't think this would be a > backwards-compatible implementation. Today, the return value of > clear-message-function isn't used, so we have to assume that users of > that variable returns... whatever. Giving it semantics now would lead > to the message area being preserved unexpectedly. To be able to use clear-message-function in Emacs 29, we need to issue a notification in Emacs 28 NEWS: diff --git a/etc/NEWS b/etc/NEWS index 8e38c3690c..69d00a8bf1 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -3327,6 +3327,10 @@ This new 'etc-authors-mode' provides font-locking for displaying the * Incompatible Lisp Changes in Emacs 28.1 +--- +** The return value of 'clear-message-function' will change in later releases. +When it will return a non-nil, the echo area won't be cleared. + +++ ** Emacs now prints a backtrace when signaling an error in batch mode. This makes debugging Emacs Lisp scripts run in batch mode easier. To -- From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Dec 2021 19:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163873376812415 (code B ref 40774); Sun, 05 Dec 2021 19:50:01 +0000 Received: (at 40774) by debbugs.gnu.org; 5 Dec 2021 19:49:28 +0000 Received: from localhost ([127.0.0.1]:59538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtxVo-0003EB-8w for submit@debbugs.gnu.org; Sun, 05 Dec 2021 14:49:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtxVm-0003Dy-Kw for 40774@debbugs.gnu.org; Sun, 05 Dec 2021 14:49:27 -0500 Received: from [2001:470:142:3::e] (port=47900 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 1mtxVh-0000mZ-9I; Sun, 05 Dec 2021 14:49:21 -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=kUhVDW97Gqcxew+u7f4pcSkMicHpqDTdLf8caRHYFes=; b=HCS2BwU7QsM7 BY5db+YgAU4JUIhiAAhpX6p6PmxEq5yIxekX8rN21GdJ+Dcz2tWYmutdlgU2h2St+5EYZ5yTzxTiF pz0aLbPW89ubmUS5PSNnDO5EK7oN9ZCkPwHPGKI1mhyFBLEwTqAlIPOR6zqJ70S5L5tXENMHD/Hku 4bgX+ynOvMjXHP9gj69ZPrWGbCPQYhr6WV7XH9MK4Ha8b27vCEwBL43vKlXrwzSHL6m6MTWOcwXhn qUGlXwq7MkONuI9dbiI7wbsuZ/Z9COUDpRYHIySVk2Vj30dt5gSG0U7zHzG4wQejWsoQNHEUGFNPm GhdlRTRMtjxB3sXjjfWsbw==; Received: from [87.69.77.57] (port=2311 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 1mtxVh-0005bu-1B; Sun, 05 Dec 2021 14:49:21 -0500 Date: Sun, 05 Dec 2021 21:49:16 +0200 Message-Id: <83h7bm3k8z.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86pmqa51cz.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 05 Dec 2021 20:54:20 +0200) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com > Date: Sun, 05 Dec 2021 20:54:20 +0200 > > To be able to use clear-message-function in Emacs 29, > we need to issue a notification in Emacs 28 NEWS: > > diff --git a/etc/NEWS b/etc/NEWS > index 8e38c3690c..69d00a8bf1 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -3327,6 +3327,10 @@ This new 'etc-authors-mode' provides font-locking for displaying the > > * Incompatible Lisp Changes in Emacs 28.1 > > +--- > +** The return value of 'clear-message-function' will change in later releases. > +When it will return a non-nil, the echo area won't be cleared. > + We never did anything like that before, AFAIR. Why is this needed, and how is this change different from any other change in behavior? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Dec 2021 20:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163873745412181 (code B ref 40774); Sun, 05 Dec 2021 20:51:02 +0000 Received: (at 40774) by debbugs.gnu.org; 5 Dec 2021 20:50:54 +0000 Received: from localhost ([127.0.0.1]:59745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtyTG-0003AP-2b for submit@debbugs.gnu.org; Sun, 05 Dec 2021 15:50:54 -0500 Received: from quimby.gnus.org ([95.216.78.240]:56088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtyTE-0003AC-JT for 40774@debbugs.gnu.org; Sun, 05 Dec 2021 15:50:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uMzJ/ZiCWWmwDxEmTdAEy2Ex4Aab8qsweB1yrYHc3AA=; b=C4cm+061dbKWC5Tw4DleOiMtw4 dtNQeMBWBn86KPa3MTPwkXmfpBnr0W172P5D8S7dh+36xHzlibdItm30fd+pXtne7UburkoBQllMj Gx0Wb/D4obM/WARwFbrQdTYIGRlRPSHKAzj4jsoyITYq8vnFMWhsVmQHzkBW/IZcYp2U=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtyT1-0002qv-99; Sun, 05 Dec 2021 21:50:42 +0100 From: Lars Ingebrigtsen 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEU/Fhi/qJ22FiP/ ///QDgF2AAAAAWJLR0QDEQxM8gAAAAd0SU1FB+UMBRQXL80Oj8EAAAFTSURBVCjPTdGxasMwEAbg 3yKGoCmBurOXFqOnSKFZMjVQG+o9S55CCArBW4dkyKQYWsT/lL2TY4gNkj6fTnfIgDzFAm4YeNX1 erOCSyQV7QeMC+SfbhI01k2RYruBBzkKiv0nLPS7A0rZVVsylTvgfbsxtWSgPGKxXsHWGjA7VBUQ DRmr9oiqlYBTHI7YS7oG8CM5sks78Ti/EU+Q4lKirY6EQbRJqrYvA2HNibHsi0NhpZ3aC7qv7qJo LMfX53VHQUiOt9/u1kl7iHJuPHRjhhZJL/31ovACfvdnKoyC/ZCR1xc+gLK0TBMGeQNH3L/r5TyA c86MoEVnxDBjkNMCbUaSe5CsGR7j0tnkMuQC/R3SAFKwRjEqWLuMKPngMkIRJB8coolOm5CfSDY2 5gMU42lCUiQ/IWbIAVJx9FOOjJEWGcs8uQk+T82EmKdpzAVMjv8Dvofiv+ZbvdIAAAAldEVYdGRh dGU6Y3JlYXRlADIwMjEtMTItMDVUMjA6MjM6NDcrMDA6MDBj5hSIAAAAJXRFWHRkYXRlOm1vZGlm eQAyMDIxLTEyLTA1VDIwOjIzOjQ3KzAwOjAwErusNAAAAABJRU5ErkJggg== X-Now-Playing: Kraftwerk's _The Man Machine_: "Neon Lights" Date: Sun, 05 Dec 2021 21:50:38 +0100 In-Reply-To: <86pmqa51cz.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 05 Dec 2021 20:54:20 +0200") Message-ID: <87bl1uojxd.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > +** The return value of 'clear-message-function' will change in later releases. > +When it will return a non-nil, the echo area won't be cleared. I think I opined that we probably shouldn't introduce any semantics for these functions here, because it might break people's code in subtle ways. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > +** The return value of 'clear-message-function' will change in later releases. > +When it will return a non-nil, the echo area won't be cleared. I think I opined that we probably shouldn't introduce any semantics for these functions here, because it might break people's code in subtle ways. So if we want this, we should probably introduce a new facility of some kind (and perhaps obsolete the old one), to have an orderly transition. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Dec 2021 21:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16387406002003 (code B ref 40774); Sun, 05 Dec 2021 21:44:02 +0000 Received: (at 40774) by debbugs.gnu.org; 5 Dec 2021 21:43:20 +0000 Received: from localhost ([127.0.0.1]:59869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtzI0-0000WF-Cz for submit@debbugs.gnu.org; Sun, 05 Dec 2021 16:43:20 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:59171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtzHy-0000W2-JS for 40774@debbugs.gnu.org; Sun, 05 Dec 2021 16:43:18 -0500 Received: (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 5151220003; Sun, 5 Dec 2021 21:43:09 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET 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> Date: Sun, 05 Dec 2021 23:29:53 +0200 In-Reply-To: <87bl1uojxd.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 05 Dec 2021 21:50:38 +0100") Message-ID: <86czmakaem.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> +** The return value of 'clear-message-function' will change in later releases. >> +When it will return a non-nil, the echo area won't be cleared. > > I think I opined that we probably shouldn't introduce any semantics for > these functions here, because it might break people's code in subtle > ways. > > So if we want this, we should probably introduce a new facility of some > kind (and perhaps obsolete the old one), to have an orderly transition. Maybe, add a new function 'clear-message-function-2', then in the next release delete 'clear-message-function', and after the next release rename 'clear-message-function-2' to 'clear-message-function'. Sorry, couldn't resist, this is not serious 🤭 But really it's not worth the trouble. I counted 60 incompatible Lisp changes in Emacs 28.1. And if we will make this change now, the authors will have enough time to adapt their code (though I can't find any use of this new variable anywhere). From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Dec 2021 05:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.1638769788649 (code B ref 40774); Mon, 06 Dec 2021 05:50:02 +0000 Received: (at 40774) by debbugs.gnu.org; 6 Dec 2021 05:49:48 +0000 Received: from localhost ([127.0.0.1]:60315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mu6sm-0000AP-3r for submit@debbugs.gnu.org; Mon, 06 Dec 2021 00:49:48 -0500 Received: from quimby.gnus.org ([95.216.78.240]:60674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mu6sl-0000AC-3Y for 40774@debbugs.gnu.org; Mon, 06 Dec 2021 00:49:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LR0AM16YcBRfXDxMnTDZ87phKeQNGxNEymV09ip5CG8=; b=egRwpVyQ5+BgOnu9A8DZByRRzR GXobrodBY5TFWXriy0Mn9+7aqcChr5twfdK6AGs3LSXIyajat6vhkwhpAlFOTcSeYIPkxcj9bhxD9 9fVRYfStKfUFmX5qcBOJLDr2A+ee3tcB15Zic4+0SKqTijdb1SqjuEwr4ZHPfjXrhUYc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mu6sY-0002Z0-44; Mon, 06 Dec 2021 06:49:36 +0100 From: Lars Ingebrigtsen 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUrJi11nLmnL0aw Gi////+K8Yg8AAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UMBgUtHrYoNysAAAG1SURBVDjLjZMJbsQg DEVZLoDpBQhcIAP3v1v//yZLpUqtpZk4ed4NIZoVKxFSi4VSzEK1YCEkI4oWD4MARJMSgiWrJVYC 8FLi/g4vAjesCMsQCCqQ7lC1lECbWByYHR4aBXgWxgoRCEKbBlCDqtpSwiNr+XOsFvLR6amvkHNr c/ANIK8tt4nMYn70n2DcOlwyMowHwOnMDqbyTw/FLPydDmDaHHQY9yFQJ5pe/HLG+k5e1+zTmOW0 rxtMjAyPj8Ah0MeuyvSp6r/gv+ULwKKVBB0zfedQlN4d5DUTVbZgd7tcB2MkH9VTioNJb+2o84Xu AOHKTAArTevQPu+hB9Y4CaJAGtf+3gLitbS946sSnLh6TSR4vnGBXaNAS6joS82Wa4mIVbKl9ald 4F504xCP0ad2Ex9AK6QznqDJw6ytt7CB70mdD9SAzHltUDVRdJh5+Hof20Nb+0QBP5cEpqOhWaFz KsM3aOOI3VNsUFUWljDRBRzCBmNohbAbHgmq+kDu9RHgfCYud5RHYy1NgAs9aG7sYKVUHXDAiq/7 piM378sXTdcRt/i9qD8k9dbSbyDy9v8jwDePd3DtvJKNeAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAy MS0xMi0wNlQwNTo0NTozMCswMDowMJymWlcAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMTItMDZU MDU6NDU6MzArMDA6MDDt++LrAAAAAElFTkSuQmCC X-Now-Playing: Talking Heads's _Remain In Light (vinyl)_: "Born Under Punches (The Heat Goes On)" Date: Mon, 06 Dec 2021 06:49:33 +0100 In-Reply-To: <86czmakaem.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 05 Dec 2021 23:29:53 +0200") Message-ID: <87tufmnuz6.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > Maybe, add a new function 'clear-message-function-2', > then in the next release delete 'clear-message-function', > and after the next release rename 'clear-message-function-2' to > 'clear-message-f [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > Maybe, add a new function 'clear-message-function-2', > then in the next release delete 'clear-message-function', > and after the next release rename 'clear-message-function-2' to > 'clear-message-function'. Let's call it `new-message-function', and then in the next release, `new-message-function-final'? I think that's more up to industry standard specs. > But really it's not worth the trouble. I counted 60 incompatible > Lisp changes in Emacs 28.1. And if we will make this change now, > the authors will have enough time to adapt their code > (though I can't find any use of this new variable anywhere). It's true that it's not likely to have been used a lot, so perhaps it's an acceptable change in semantics. Perhaps try a search on Github and see whether anybody's using it there? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Dec 2021 09:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163878358623561 (code B ref 40774); Mon, 06 Dec 2021 09:40:02 +0000 Received: (at 40774) by debbugs.gnu.org; 6 Dec 2021 09:39:46 +0000 Received: from localhost ([127.0.0.1]:60554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muATK-00067x-F8 for submit@debbugs.gnu.org; Mon, 06 Dec 2021 04:39:46 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:35243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muATI-00067M-NU for 40774@debbugs.gnu.org; Mon, 06 Dec 2021 04:39:44 -0500 Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id A7007FF810; Mon, 6 Dec 2021 09:39:36 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET 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> Date: Mon, 06 Dec 2021 11:31:44 +0200 In-Reply-To: <87tufmnuz6.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 06 Dec 2021 06:49:33 +0100") Message-ID: <86bl1uyt8f.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> But really it's not worth the trouble. I counted 60 incompatible >> Lisp changes in Emacs 28.1. And if we will make this change now, >> the authors will have enough time to adapt their code >> (though I can't find any use of this new variable anywhere). > > It's true that it's not likely to have been used a lot, so perhaps it's > an acceptable change in semantics. Perhaps try a search on Github and > see whether anybody's using it there? I can't find it on Github, and this is understandable - it's a new variable with quite limited usefulness. I hoped that even if someone used it, mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient as in case of all other incompatible changes. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Dec 2021 20:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163891029219359 (code B ref 40774); Tue, 07 Dec 2021 20:52:02 +0000 Received: (at 40774) by debbugs.gnu.org; 7 Dec 2021 20:51:32 +0000 Received: from localhost ([127.0.0.1]:38794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muhQy-00052A-9J for submit@debbugs.gnu.org; Tue, 07 Dec 2021 15:51:32 -0500 Received: from quimby.gnus.org ([95.216.78.240]:53878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muhQw-00051w-P3 for 40774@debbugs.gnu.org; Tue, 07 Dec 2021 15:51:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hxpeHG7B7c2MpLaQN9J917G3+3p/nce7xZH/egcSYqI=; b=VTjBE04yEASkVP++O1SGIDGqoC qjDVwoHdhVI+L+UKuvlEZRZcc5Y010RLvZmfe5pDKcmE9JZg0GXLXWJUvxo0XjsyYseQpT4fg9PSu HsYCztnYpryN/MprFqM7lV6nfUIxHHY2IxU9e+FzocdMtCs2sx7m+RRHUscu6ejc6XAg=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muhQl-0002MH-66; Tue, 07 Dec 2021 21:51:21 +0100 From: Lars Ingebrigtsen 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAM1BMVEX+/v7Q7fxtyPqj 3fvr9fkxsvzgtMPTUZ/h1czZlmTlrpfup3KviGSfbExeUD6yVz////+BBqVmAAAAAWJLR0QQlbIN LAAAAAd0SU1FB+UMBxQSAyio3+wAAAFpSURBVEjHxZXRcoQgDEWNRDQS5P//tkkAdbvtBB+2vauA mAOXZJydps8LZpW2QS7RDA4AEAJggNDlbRFm61BWBgu2BgPKIpPhiDCD3NiApe60iJUgc6gDxZWf dTWUl0G9vAO2tr6sk3gBt4NdQMBzYqk+bzsA/AKgeXoHwg9AdYQoURZ4PwNM+AJABRB1XmZsUpqX MzRkXrR6dZFaND22OpCEWy5blnqFECTP0DrEWkyzVofaS0msLI1ozWnSUVzlF1dRjEPAasEWP7ZH jHGza3CDP9ZGe1e0dnOBlFJHZEQuwBeRElH2gHgcmRWROx8iL3GbRmXdhWzEriVd1YhsgGtJgWyu BGB5GAJy5p1YgOwDMTMzaaqIZMS+JTsvkVRARykNA2kUsCglngBU9RigR0AaBegE0hMgn57GAC7C lGeW2hHcDyjeMvpBgEvpmA8w6adWqmgMoNLjB4A9X4TZctP6XaN/Af+pL6x6Fsf3UPEvAAAAJXRF WHRkYXRlOmNyZWF0ZQAyMDIxLTEyLTA3VDIwOjE4OjAzKzAwOjAw9UGG9AAAACV0RVh0ZGF0ZTpt b2RpZnkAMjAyMS0xMi0wN1QyMDoxODowMyswMDowMIQcPkgAAAAASUVORK5CYII= X-Now-Playing: The Human League's _Dare_: "Love Action (I Believe In Love)" Date: Tue, 07 Dec 2021 21:51:14 +0100 In-Reply-To: <86bl1uyt8f.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 06 Dec 2021 11:31:44 +0200") Message-ID: <87r1aocf5p.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > I can't find it on Github, and this is understandable - it's a new variable > with quite limited usefulness. I hoped that even if someone used it, > mentioning it in the Incompatible Lisp Changes of [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > I can't find it on Github, and this is understandable - it's a new variable > with quite limited usefulness. I hoped that even if someone used it, > mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient > as in case of all other incompatible changes. OK; then I'm OK with changing the semantics in Emacs 29 (and noting this in the NEWS in Emacs 28), but perhaps Eli has an opinion here. Eli? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Dec 2021 12:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 40774@debbugs.gnu.org, ndame@protonmail.com, juri@linkov.net Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163896638730579 (code B ref 40774); Wed, 08 Dec 2021 12:27:02 +0000 Received: (at 40774) by debbugs.gnu.org; 8 Dec 2021 12:26:27 +0000 Received: from localhost ([127.0.0.1]:39704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muw1j-0007x9-2F for submit@debbugs.gnu.org; Wed, 08 Dec 2021 07:26:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muw1h-0007ww-Cs for 40774@debbugs.gnu.org; Wed, 08 Dec 2021 07:26:25 -0500 Received: from [2001:470:142:3::e] (port=55264 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 1muw1P-0002jR-Ip; Wed, 08 Dec 2021 07:26:17 -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=Yy7FerXG2/DOUFdJZEN4AKWZRadj5BeMnGPphx7DBo4=; b=fJD5LnRv1k/X 0EQ4e9GA2cWxLBBlhlfa5DvSwRNexJn89aJnMGMvhg2guKeG0f06e8MuA4zOpHffr3CW7ehw0pAvD Xf0m7+SXzBFm1axQ3WYA5uN/IgKGi+ufVlsBtlj3Flz/3XjwP9dnAuyoSI9aDTVTZMClsnTQlw0P5 MTHNkZlrDDRqmRUBadC/n3rKmXp0+Qx2Iki/XxPLIzgh6Cc/OZbzkY16+gMG19cCLUa+7RZ3wM6dJ 7XweG1+O0OHiNX7zvA1tgvHVZwgY3ZDpftILPZivH+rKCmse6miloZF5KIK1sLBHDWKeaN8WETnkd XtaOPd5qqapCLGQZmMhxNA==; Received: from [87.69.77.57] (port=2907 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 1muw1G-0000NN-0g; Wed, 08 Dec 2021 07:26:02 -0500 Date: Wed, 08 Dec 2021 14:25:38 +0200 Message-Id: <83czm7xozh.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87r1aocf5p.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 07 Dec 2021 21:51:14 +0100) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com > Date: Tue, 07 Dec 2021 21:51:14 +0100 > > Juri Linkov writes: > > > I can't find it on Github, and this is understandable - it's a new variable > > with quite limited usefulness. I hoped that even if someone used it, > > mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient > > as in case of all other incompatible changes. > > OK; then I'm OK with changing the semantics in Emacs 29 (and noting this > in the NEWS in Emacs 28), but perhaps Eli has an opinion here. Eli? This is a long discussion, and I chimed in at least twice. What exactly is the proposal for which you want my opinion? Is there some patch I could study, perhaps? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Dec 2021 19:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 40774@debbugs.gnu.org, eliz@gnu.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163899178116703 (code B ref 40774); Wed, 08 Dec 2021 19:30:02 +0000 Received: (at 40774) by debbugs.gnu.org; 8 Dec 2021 19:29:41 +0000 Received: from localhost ([127.0.0.1]:41445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv2dI-0004LL-OQ for submit@debbugs.gnu.org; Wed, 08 Dec 2021 14:29:41 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:51579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv2dH-0004Kj-6W for 40774@debbugs.gnu.org; Wed, 08 Dec 2021 14:29:39 -0500 Received: (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id A2AEC200003; Wed, 8 Dec 2021 19:29:31 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET 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> Date: Wed, 08 Dec 2021 21:18:19 +0200 In-Reply-To: <87r1aocf5p.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 07 Dec 2021 21:51:14 +0100") Message-ID: <8635n2sy6c.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> I can't find it on Github, and this is understandable - it's a new variable >> with quite limited usefulness. I hoped that even if someone used it, >> mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient >> as in case of all other incompatible changes. > > OK; then I'm OK with changing the semantics in Emacs 29 (and noting this > in the NEWS in Emacs 28), but perhaps Eli has an opinion here. Eli? I even further reduced the incompatibilities by using new logic only on the value 't' returned by the function, instead of any non-nil value. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Dec 2021 19:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40774@debbugs.gnu.org, Lars Ingebrigtsen , ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163899178516719 (code B ref 40774); Wed, 08 Dec 2021 19:30:03 +0000 Received: (at 40774) by debbugs.gnu.org; 8 Dec 2021 19:29:45 +0000 Received: from localhost ([127.0.0.1]:41448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv2dN-0004Lb-CD for submit@debbugs.gnu.org; Wed, 08 Dec 2021 14:29:45 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:34053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv2dL-0004L1-4h for 40774@debbugs.gnu.org; Wed, 08 Dec 2021 14:29:43 -0500 Received: (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BE5F660009; Wed, 8 Dec 2021 19:29:35 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET 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> Date: Wed, 08 Dec 2021 21:21:22 +0200 In-Reply-To: <83czm7xozh.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Dec 2021 14:25:38 +0200") Message-ID: <86wnkerjgt.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> > I can't find it on Github, and this is understandable - it's a new variable >> > with quite limited usefulness. I hoped that even if someone used it, >> > mentioning it in the Incompatible Lisp Changes of NEWS would be sufficient >> > as in case of all other incompatible changes. >> >> OK; then I'm OK with changing the semantics in Emacs 29 (and noting this >> in the NEWS in Emacs 28), but perhaps Eli has an opinion here. Eli? > > This is a long discussion, and I chimed in at least twice. What > exactly is the proposal for which you want my opinion? Is there some > patch I could study, perhaps? The updated patch is here: diff --git a/etc/NEWS b/etc/NEWS index 55e3216e41..8a92a0dcaa 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -718,6 +718,11 @@ Emacs buffers, like indentation and the like. The new ert function * Incompatible Lisp Changes in Emacs 29.1 +--- +** 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. + ** User option 'mail-source-ignore-errors' is now obsolete. The whole mechanism for prompting users to continue in case of mail-source errors has been removed, so this option is no longer diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 28bd1df59a..d8db8898f1 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -864,7 +945,11 @@ clear-minibuffer-message (setq minibuffer-message-timer nil)) (when (overlayp minibuffer-message-overlay) (delete-overlay minibuffer-message-overlay) - (setq minibuffer-message-overlay nil)))) + (setq minibuffer-message-overlay nil))) + + ;; Return nil telling the caller that the message + ;; should be also handled by the caller. + nil) (setq clear-message-function 'clear-minibuffer-message) diff --git a/src/xdisp.c b/src/xdisp.c index 0ff6286af7..c79168b1be 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -12521,18 +12521,23 @@ set_message_1 (void *a1, Lisp_Object string) void clear_message (bool current_p, bool last_displayed_p) { + Lisp_Object preserve = Qnil; + if (current_p) { - echo_area_buffer[0] = Qnil; - message_cleared_p = true; - if (FUNCTIONP (Vclear_message_function)) { ptrdiff_t count = SPECPDL_INDEX (); specbind (Qinhibit_quit, Qt); - safe_call (1, Vclear_message_function); + preserve = safe_call (1, Vclear_message_function); unbind_to (count, Qnil); } + + if (!EQ (preserve, Qt)) + { + echo_area_buffer[0] = Qnil; + message_cleared_p = true; + } } if (last_displayed_p) @@ -36232,9 +36237,13 @@ syms_of_xdisp (void) DEFVAR_LISP ("clear-message-function", Vclear_message_function, doc: /* If non-nil, function to clear echo-area messages. Usually this function is called when the next input event arrives. -The function is called without arguments. It is expected to clear the -message displayed by its counterpart function specified by -`set-message-function'. */); +It is expected to clear the message displayed by its counterpart +function specified by `set-message-function'. +The function is called without arguments. +If this function returns a non-t value, the message is cleared +from the echo area as usual. If this function returns t, +this means that the message was already handled, and the original +message text will not be cleared from the echo area. */); Vclear_message_function = Qnil; DEFVAR_LISP ("redisplay--all-windows-cause", Vredisplay__all_windows_cause, -- From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle 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 X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163899370019789 (code B ref 40774); Wed, 08 Dec 2021 20:02:02 +0000 Received: (at 40774) by debbugs.gnu.org; 8 Dec 2021 20:01:40 +0000 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 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 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==; 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 Date: Wed, 08 Dec 2021 22:01:14 +0200 Message-Id: <8335n2x3w5.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86wnkerjgt.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 08 Dec 2021 21:21:22 +0200) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2021 19:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16393368453594 (code B ref 40774); Sun, 12 Dec 2021 19:21:02 +0000 Received: (at 40774) by debbugs.gnu.org; 12 Dec 2021 19:20:45 +0000 Received: from localhost ([127.0.0.1]:53178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUOr-0000vu-L2 for submit@debbugs.gnu.org; Sun, 12 Dec 2021 14:20:45 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:42921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUOp-0000vg-PO for 40774@debbugs.gnu.org; Sun, 12 Dec 2021 14:20:44 -0500 Received: (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 6E769200004; Sun, 12 Dec 2021 19:20:36 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET 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> <8335n2x3w5.fsf@gnu.org> Date: Sun, 12 Dec 2021 21:19:41 +0200 In-Reply-To: <8335n2x3w5.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 08 Dec 2021 22:01:14 +0200") Message-ID: <865yrtiqb6.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> +** 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. What a special value would you prefer? Maybe, a symbol 'no'? > 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? When the return value is nil, it will still clear the echo area. > More generally, I fear that we are trying very hard to tweak a > particular infrastructure for a job for which it was hardly meant. This is the most simple and thus reliable solution. > 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? This is exactly what functions bound to clear-message-function intended to do. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2021 19:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16393385826399 (code B ref 40774); Sun, 12 Dec 2021 19:50:01 +0000 Received: (at 40774) by debbugs.gnu.org; 12 Dec 2021 19:49:42 +0000 Received: from localhost ([127.0.0.1]:53208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUqs-0001f9-Dx for submit@debbugs.gnu.org; Sun, 12 Dec 2021 14:49:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUqq-0001ew-IT for 40774@debbugs.gnu.org; Sun, 12 Dec 2021 14:49:41 -0500 Received: from [2001:470:142:3::e] (port=38744 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 1mwUqk-00045a-JS; Sun, 12 Dec 2021 14:49:34 -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=60/XiD2qdrbzQkp8PS4/1r+e/4dHwaoyeokNdP8zjn0=; b=ZxiymRGA5yqm D+tp1zYB5rTsr4V+9Jv4JzQkveeQecmGJz42cPfDOuLn30LhPASCnbmsbB/sycYKSlmTF4mJWyxZw x/8YAC8GEJEHBPsDrtoZKP2jNCwH7+sFSj6hDaubUXLNojeSHoEgPJs6ht1bO2/H8XpGyJ4+170XJ tcLMwCetDAsMF0i4YPLBe6aa9xh7VsL5HaddwpklLM0lJGf6I2KP7U5VUOCslrCzOcqH1hPXI8BF9 O9OHaMeGQgXI2E97gMo4paE1Y1qvcpipHLIr+6e+XtQ6CwxiN2TvSAxu33GElnMN+Q9/4UL8aniho LjidNgBkDS+DAwuhwKz3dw==; Received: from [87.69.77.57] (port=3530 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 1mwUqk-0000Od-8w; Sun, 12 Dec 2021 14:49:34 -0500 Date: Sun, 12 Dec 2021 21:49:26 +0200 Message-Id: <83wnk9mwmx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <865yrtiqb6.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 12 Dec 2021 21:19:41 +0200) 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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, 40774@debbugs.gnu.org, ndame@protonmail.com > Date: Sun, 12 Dec 2021 21:19:41 +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. > > What a special value would you prefer? Maybe, a symbol 'no'? More like 'no-clear or even 'dont-clear-message, I think. > > 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? > > When the return value is nil, it will still clear the echo area. That wasn't what I asked. I asked whether the change in the order could matter. Specifically, we now set echo_area_buffer[0] to nil after we run clear-message-function, not before. Can that affect some customization of clear-message-function? > > More generally, I fear that we are trying very hard to tweak a > > particular infrastructure for a job for which it was hardly meant. > > This is the most simple and thus reliable solution. > > > 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? > > This is exactly what functions bound to clear-message-function intended to do. ??? This function is about _clearing_ the echo-area, whereas I was talking about the _display_ in the echo-area. I'm saying that I'm not sure echo-area display is suited for the jobs that this bug wants it to do. As an example, I asked what would happen when the echo-area can no longer be resized to accommodate all the messages that were not cleared. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2021 20:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16393404659298 (code B ref 40774); Sun, 12 Dec 2021 20:22:02 +0000 Received: (at 40774) by debbugs.gnu.org; 12 Dec 2021 20:21:05 +0000 Received: from localhost ([127.0.0.1]:53244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwVLE-0002Pu-QH for submit@debbugs.gnu.org; Sun, 12 Dec 2021 15:21:05 -0500 Received: from relay10.mail.gandi.net ([217.70.178.230]:33145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwVLC-0002Ol-Qs for 40774@debbugs.gnu.org; Sun, 12 Dec 2021 15:21:03 -0500 Received: (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 3CCA4240004; Sun, 12 Dec 2021 20:20:54 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> Date: Sun, 12 Dec 2021 22:18:29 +0200 In-Reply-To: <83wnk9mwmx.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Dec 2021 21:49:26 +0200") Message-ID: <86v8ztfuga.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> >> +** 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. >> >> What a special value would you prefer? Maybe, a symbol 'no'? > > More like 'no-clear or even 'dont-clear-message, I think. I tried to find an existing DEFSYM in syms_of_xdisp, but it seems there is no suitable symbol, so a new symbol 'dont-clear-message' could be added to syms_of_xdisp. This is a patch over the previous patch: diff --git a/src/xdisp.c b/src/xdisp.c index 9b5b7d49e5..495a84b349 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -12533,7 +12533,7 @@ clear_message (bool current_p, bool last_displayed_p) unbind_to (count, Qnil); } - if (!EQ (preserve, Qt)) + if (!EQ (preserve, Qdont_clear_message)) { echo_area_buffer[0] = Qnil; message_cleared_p = true; @@ -36235,6 +36235,7 @@ syms_of_xdisp (void) (which controls how error messages are displayed). */); Vset_message_function = Qnil; + DEFSYM (Qdont_clear_message, "dont-clear-message"); DEFVAR_LISP ("clear-message-function", Vclear_message_function, doc: /* If non-nil, function to clear echo-area messages. >> > 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? >> >> When the return value is nil, it will still clear the echo area. > > That wasn't what I asked. I asked whether the change in the order > could matter. Specifically, we now set echo_area_buffer[0] to nil > after we run clear-message-function, not before. Can that affect > some customization of clear-message-function? Actually, it should not affect customizations because such customizations should not touch the echo-area. It's the task of clear_message to handle the echo-area. >> > More generally, I fear that we are trying very hard to tweak a >> > particular infrastructure for a job for which it was hardly meant. >> >> This is the most simple and thus reliable solution. >> >> > 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? >> >> This is exactly what functions bound to clear-message-function intended to do. > > ??? This function is about _clearing_ the echo-area, whereas I was > talking about the _display_ in the echo-area. I'm saying that I'm not > sure echo-area display is suited for the jobs that this bug wants it > to do. As an example, I asked what would happen when the echo-area > can no longer be resized to accommodate all the messages that were not > cleared. clear-message-function can handle not only echo-area but also e.g. the minibuffer messages. In case of the returned value, by using 'dont-clear-message' it can sometimes tell the function clear_message to not clear the echo-area, so there are no resizing problems. It doesn't add more lines to the existing echo-area. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2021 16:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163941412127969 (code B ref 40774); Mon, 13 Dec 2021 16:49:01 +0000 Received: (at 40774) by debbugs.gnu.org; 13 Dec 2021 16:48:41 +0000 Received: from localhost ([127.0.0.1]:56665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwoVF-0007H3-9X for submit@debbugs.gnu.org; Mon, 13 Dec 2021 11:48:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53110) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwoVA-0007Gn-3o for 40774@debbugs.gnu.org; Mon, 13 Dec 2021 11:48:39 -0500 Received: from [2001:470:142:3::e] (port=36446 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 1mwoV4-0005p9-73; Mon, 13 Dec 2021 11:48:30 -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=g4swwqvESH7Ii0yf9TVsC3pnjdhV4R0INZiHzRezUCo=; b=XqGXTAKhReZY pn3udy+rytHHIvl5nQ6ttnCRe56EbSwZ4JxLy8rovnHbyXwiQ8uquSopeNt+BAwna20hKPdXYvDu6 4mhWr0dF4WRxYVbbaEsb0/XaIacg1YfRTyV+xk5rbbWe9grNN0kz6mqIJ+Uu350xRGXZHBZ2q+deM G1iVYrhW6UTc0+o596UILzHqEc1kzvSNuMjyProBPoo3GaoFQ/J8c/y37bpmQkP2BFJIoHQ36x0YN sb8BL7sUZU1doEfFthW1FVmFcmHx5dBBgTE0ZchrKeEz2hcIc0O4U4eJVe84nrAhJ6m/MqhqKmGXX FFQf0w70NjqLe30TtBLpKw==; Received: from [87.69.77.57] (port=1113 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 1mwoV4-000774-0P; Mon, 13 Dec 2021 11:48:30 -0500 Date: Mon, 13 Dec 2021 18:48:24 +0200 Message-Id: <831r2gmox3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86v8ztfuga.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 12 Dec 2021 22:18:29 +0200) References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, 40774@debbugs.gnu.org, ndame@protonmail.com > Date: Sun, 12 Dec 2021 22:18:29 +0200 > > >> > 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? > >> > >> When the return value is nil, it will still clear the echo area. > > > > That wasn't what I asked. I asked whether the change in the order > > could matter. Specifically, we now set echo_area_buffer[0] to nil > > after we run clear-message-function, not before. Can that affect > > some customization of clear-message-function? > > Actually, it should not affect customizations because such customizations > should not touch the echo-area. It's the task of clear_message > to handle the echo-area. Isn't there some Lisp-visible effect of that, like that the echo-area will appear empty after the assignment? If so, then the clear-message-function was previously running with the echo-area buffer nil, but now it won't. > >> > 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? > >> > >> This is exactly what functions bound to clear-message-function intended to do. > > > > ??? This function is about _clearing_ the echo-area, whereas I was > > talking about the _display_ in the echo-area. I'm saying that I'm not > > sure echo-area display is suited for the jobs that this bug wants it > > to do. As an example, I asked what would happen when the echo-area > > can no longer be resized to accommodate all the messages that were not > > cleared. > > clear-message-function can handle not only echo-area but also e.g. > the minibuffer messages. In case of the returned value, by using > 'dont-clear-message' it can sometimes tell the function clear_message > to not clear the echo-area, so there are no resizing problems. > It doesn't add more lines to the existing echo-area. I gave an example of how using this for that purpose could be a problem, and you responded only to that example. But the problem that bothers me is much more general, and you are silent about that larger problem. I'm asking once again: aren't we trying to use echo-area messages or minibuffer messages displayed in the mini-window for a job that they weren't intended to do: showing large amounts of messages at the same time? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2021 19:21:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16394232389721 (code B ref 40774); Mon, 13 Dec 2021 19:21:03 +0000 Received: (at 40774) by debbugs.gnu.org; 13 Dec 2021 19:20:38 +0000 Received: from localhost ([127.0.0.1]:56852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwqsH-0002Wi-TD for submit@debbugs.gnu.org; Mon, 13 Dec 2021 14:20:38 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:47335) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwqsE-0002WS-3p for 40774@debbugs.gnu.org; Mon, 13 Dec 2021 14:20:36 -0500 Received: (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id B0DF740005; Mon, 13 Dec 2021 19:20:26 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> <831r2gmox3.fsf@gnu.org> Date: Mon, 13 Dec 2021 20:50:36 +0200 In-Reply-To: <831r2gmox3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Dec 2021 18:48:24 +0200") Message-ID: <86sfuwnxtv.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> >> > 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? >> >> >> >> When the return value is nil, it will still clear the echo area. >> > >> > That wasn't what I asked. I asked whether the change in the order >> > could matter. Specifically, we now set echo_area_buffer[0] to nil >> > after we run clear-message-function, not before. Can that affect >> > some customization of clear-message-function? >> >> Actually, it should not affect customizations because such customizations >> should not touch the echo-area. It's the task of clear_message >> to handle the echo-area. > > Isn't there some Lisp-visible effect of that, like that the echo-area > will appear empty after the assignment? If so, then the > clear-message-function was previously running with the echo-area > buffer nil, but now it won't. clear-message-function is not intended to do anything with the echo-area. Its purpose is to notify a subscriber that the message is going to be cleared, so the subscriber can e.g. clear the message from the minibuffer, etc. When the subscriber needs to affect the echo-area, it's the purpose of the proposed return value not to clear the echo-area when the subscriber asks so via the return value. >> >> > 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? >> >> >> >> This is exactly what functions bound to clear-message-function intended to do. >> > >> > ??? This function is about _clearing_ the echo-area, whereas I was >> > talking about the _display_ in the echo-area. I'm saying that I'm not >> > sure echo-area display is suited for the jobs that this bug wants it >> > to do. As an example, I asked what would happen when the echo-area >> > can no longer be resized to accommodate all the messages that were not >> > cleared. >> >> clear-message-function can handle not only echo-area but also e.g. >> the minibuffer messages. In case of the returned value, by using >> 'dont-clear-message' it can sometimes tell the function clear_message >> to not clear the echo-area, so there are no resizing problems. >> It doesn't add more lines to the existing echo-area. > > I gave an example of how using this for that purpose could be a > problem, and you responded only to that example. But the problem that > bothers me is much more general, and you are silent about that larger > problem. > > I'm asking once again: aren't we trying to use echo-area messages or > minibuffer messages displayed in the mini-window for a job that they > weren't intended to do: showing large amounts of messages at the same > time? Sorry, I still don't understand what do you mean. What large amounts of messages? At what the same time? This is completely unclear. Maybe if you give an example, this could help to understand. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Dec 2021 19:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163942455511796 (code B ref 40774); Mon, 13 Dec 2021 19:43:01 +0000 Received: (at 40774) by debbugs.gnu.org; 13 Dec 2021 19:42:35 +0000 Received: from localhost ([127.0.0.1]:56891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwrDW-00034C-Ov for submit@debbugs.gnu.org; Mon, 13 Dec 2021 14:42:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwrDU-00033x-Ge for 40774@debbugs.gnu.org; Mon, 13 Dec 2021 14:42:32 -0500 Received: from [2001:470:142:3::e] (port=42280 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 1mwrDO-0000lU-Bi; Mon, 13 Dec 2021 14:42:26 -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=dGXN/9DCIGILtWJZ6vkqyKpPzUTdZxzsPg6/N0S1PU4=; b=Yru6/Bgpi5hE LHolP0eYgW+NeUhHIlx3Q3yKoAYwQsUNrjKSPpAaoVpn3ZdyuNvk+EebgNk7GfBAaReGNXGo+8ato bQ+E7OqSQxH4fqKC+U+L1wuZQcNsDE9dqWpkdO+E0NACNSD/0MgR+y1ECh6ARlCTCBjtDImLr73xS km4tU/AwxCQ7NpHYHc/F8NTjZIDkBf0uAz5VMbizWBwlfySC3Enke8JZ3tqJrNIsfB9nxA7BbI+8J 5vFe9hcF1lrkH8JNNv6Od4ZGjUWZVlLm9Nj5GtF0CCfeD8j4cLU7K+OcCXK2pUoP3QdYB1u6qhztN AnqoCi27Y7GO0JOvilesRA==; Received: from [87.69.77.57] (port=4013 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 1mwrDO-00034R-2C; Mon, 13 Dec 2021 14:42:26 -0500 Date: Mon, 13 Dec 2021 21:42:21 +0200 Message-Id: <83o85kl2aq.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86sfuwnxtv.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 13 Dec 2021 20:50:36 +0200) References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> <831r2gmox3.fsf@gnu.org> <86sfuwnxtv.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, 40774@debbugs.gnu.org, ndame@protonmail.com > Date: Mon, 13 Dec 2021 20:50:36 +0200 > > > Isn't there some Lisp-visible effect of that, like that the echo-area > > will appear empty after the assignment? If so, then the > > clear-message-function was previously running with the echo-area > > buffer nil, but now it won't. > > clear-message-function is not intended to do anything with the echo-area. > Its purpose is to notify a subscriber that the message is going to be cleared, > so the subscriber can e.g. clear the message from the minibuffer, etc. > When the subscriber needs to affect the echo-area, it's the purpose > of the proposed return value not to clear the echo-area when the subscriber > asks so via the return value. So there will be some effect of this reordering, if some clear-message-function does something that you say it shouldn't. > > I gave an example of how using this for that purpose could be a > > problem, and you responded only to that example. But the problem that > > bothers me is much more general, and you are silent about that larger > > problem. > > > > I'm asking once again: aren't we trying to use echo-area messages or > > minibuffer messages displayed in the mini-window for a job that they > > weren't intended to do: showing large amounts of messages at the same > > time? > > Sorry, I still don't understand what do you mean. What large amounts > of messages? At what the same time? This is completely unclear. > Maybe if you give an example, this could help to understand. This whole discussion started from a request to be able to accumulate messages in the echo-area so that the user who is away could see them all when he/she comes back from whatever took him/her away. There could be quite a lot of messages accumulated during that period, and the request was to leave them all on display. For which you proposed to use clear-message-function in a way that doesn't actually clear them. Is the above an accurate description and summary of what is being proposed here? If so, is it now clear what kind of job I think display of echo-area messages was never designed to support? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Dec 2021 09:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16394723847978 (code B ref 40774); Tue, 14 Dec 2021 09:00:02 +0000 Received: (at 40774) by debbugs.gnu.org; 14 Dec 2021 08:59:44 +0000 Received: from localhost ([127.0.0.1]:57562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx3ey-00024c-HC for submit@debbugs.gnu.org; Tue, 14 Dec 2021 03:59:44 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:40607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx3ev-000249-8R for 40774@debbugs.gnu.org; Tue, 14 Dec 2021 03:59:41 -0500 Received: (Authenticated sender: juri@linkov.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 1F85BC000E; Tue, 14 Dec 2021 08:59:32 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET References: <-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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> <831r2gmox3.fsf@gnu.org> <86sfuwnxtv.fsf@mail.linkov.net> <83o85kl2aq.fsf@gnu.org> Date: Tue, 14 Dec 2021 10:35:13 +0200 In-Reply-To: <83o85kl2aq.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Dec 2021 21:42:21 +0200") Message-ID: <86ee6f4mqe.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> > Isn't there some Lisp-visible effect of that, like that the echo-area >> > will appear empty after the assignment? If so, then the >> > clear-message-function was previously running with the echo-area >> > buffer nil, but now it won't. >> >> clear-message-function is not intended to do anything with the echo-area. >> Its purpose is to notify a subscriber that the message is going to be cleared, >> so the subscriber can e.g. clear the message from the minibuffer, etc. >> When the subscriber needs to affect the echo-area, it's the purpose >> of the proposed return value not to clear the echo-area when the subscriber >> asks so via the return value. > > So there will be some effect of this reordering, if some > clear-message-function does something that you say it shouldn't. Of course, when authors decide to shoot themselves in the foot, we can't prevent this. >> > I gave an example of how using this for that purpose could be a >> > problem, and you responded only to that example. But the problem that >> > bothers me is much more general, and you are silent about that larger >> > problem. >> > >> > I'm asking once again: aren't we trying to use echo-area messages or >> > minibuffer messages displayed in the mini-window for a job that they >> > weren't intended to do: showing large amounts of messages at the same >> > time? >> >> Sorry, I still don't understand what do you mean. What large amounts >> of messages? At what the same time? This is completely unclear. >> Maybe if you give an example, this could help to understand. > > This whole discussion started from a request to be able to accumulate > messages in the echo-area so that the user who is away could see them > all when he/she comes back from whatever took him/her away. There > could be quite a lot of messages accumulated during that period, and > the request was to leave them all on display. For which you proposed > to use clear-message-function in a way that doesn't actually clear > them. > > Is the above an accurate description and summary of what is being > proposed here? If so, is it now clear what kind of job I think > display of echo-area messages was never designed to support? Thanks for explanation, now it's clear where is the misunderstanding. Actually, the patch for clear-message-function here is unrelated to the feature that uses set-message-function to accumulate messages and doesn't use clear-message-function. The feature here is intended for users who want to always leave the last displayed message in the echo-area, and never clear it. It will be possible even to do this conditionally. For example, when the user wants to leave the message "Compilation finished" displayed in the echo area even during navigation in the buffer or when the user types text. Normally such message will be cleared on any key press, and thus the user will miss it. But with such configuration the user won't miss the message even while using self-inserting or navigation keys when the message is displayed: (setq clear-message-function (lambda () (when (string-match-p "^Compilation" (current-message)) 'dont-clear-message))) From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Dec 2021 13:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.16394879788445 (code B ref 40774); Tue, 14 Dec 2021 13:20:02 +0000 Received: (at 40774) by debbugs.gnu.org; 14 Dec 2021 13:19:38 +0000 Received: from localhost ([127.0.0.1]:57817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx7iT-0002C7-Lk for submit@debbugs.gnu.org; Tue, 14 Dec 2021 08:19:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mx7iH-0002Bj-6D for 40774@debbugs.gnu.org; Tue, 14 Dec 2021 08:19:36 -0500 Received: from [2001:470:142:3::e] (port=38014 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 1mx7iA-0001uN-4Q; Tue, 14 Dec 2021 08:19:18 -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=qMhHuCPsGK5pXVGfV4Ry5AHJXTx+YT8y7ebt3hUrHI0=; b=OEZz4JQGZ4rz xCNs5ForrMof199D5OR7jxMRlP659NNj0kBJYS0vIiG0TAsuO56WBWtrodLHIciiYVQxER1x2ii3/ iHPKgRTpPawUmcEaLgICxyuh1vPHZU9AJHBbwqk2RCpMYIwqN9M/wp6A+xK5LG6Ug47elVFEgTwvD vPRKAm7UgdzJxkq+NqmUWIO+dco4nm3PXtL+Cl2EIxoaMBIl586R1h9pZe+/eg6Tgp14kTz1riPpN 0atIpIT/RZzbwuGn7ovh3z/ixEA0ttGfKEojhJZeIq5Dgz69+hq5DD8ECIua/vZrnCETzMKioR5oJ B93+RPrGcFRbVEZIxHTpGA==; Received: from [87.69.77.57] (port=4924 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 1mx7hv-00010P-Cc; Tue, 14 Dec 2021 08:19:06 -0500 Date: Tue, 14 Dec 2021 15:19:00 +0200 Message-Id: <83ee6fl3y3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86ee6f4mqe.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 14 Dec 2021 10:35:13 +0200) References: <-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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> <831r2gmox3.fsf@gnu.org> <86sfuwnxtv.fsf@mail.linkov.net> <83o85kl2aq.fsf@gnu.org> <86ee6f4mqe.fsf@mail.linkov.net> X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, 40774@debbugs.gnu.org, ndame@protonmail.com > Date: Tue, 14 Dec 2021 10:35:13 +0200 > > > So there will be some effect of this reordering, if some > > clear-message-function does something that you say it shouldn't. > > Of course, when authors decide to shoot themselves in the foot, > we can't prevent this. They might say we shoot them in their foot, by changing the order. > > This whole discussion started from a request to be able to accumulate > > messages in the echo-area so that the user who is away could see them > > all when he/she comes back from whatever took him/her away. There > > could be quite a lot of messages accumulated during that period, and > > the request was to leave them all on display. For which you proposed > > to use clear-message-function in a way that doesn't actually clear > > them. > > > > Is the above an accurate description and summary of what is being > > proposed here? If so, is it now clear what kind of job I think > > display of echo-area messages was never designed to support? > > Thanks for explanation, now it's clear where is the misunderstanding. > > Actually, the patch for clear-message-function here is unrelated > to the feature that uses set-message-function to accumulate messages > and doesn't use clear-message-function. > > The feature here is intended for users who want to always leave > the last displayed message in the echo-area, and never clear it. > It will be possible even to do this conditionally. But if messages aren't cleared, they will accumulate, and then we get to the problems I described. So it is not "unrelated", really. In any case, if this feature is unrelated, why do you want to have it on the release branch? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Dec 2021 21:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163951626030451 (code B ref 40774); Tue, 14 Dec 2021 21:11:02 +0000 Received: (at 40774) by debbugs.gnu.org; 14 Dec 2021 21:11:00 +0000 Received: from localhost ([127.0.0.1]:59764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxF4d-0007v4-Qg for submit@debbugs.gnu.org; Tue, 14 Dec 2021 16:11:00 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:51201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxF4b-0007uW-Jh for 40774@debbugs.gnu.org; Tue, 14 Dec 2021 16:10:57 -0500 Received: (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 19D13E0005; Tue, 14 Dec 2021 21:10:49 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> <831r2gmox3.fsf@gnu.org> <86sfuwnxtv.fsf@mail.linkov.net> <83o85kl2aq.fsf@gnu.org> <86ee6f4mqe.fsf@mail.linkov.net> <83ee6fl3y3.fsf@gnu.org> Date: Tue, 14 Dec 2021 22:54:53 +0200 In-Reply-To: <83ee6fl3y3.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Dec 2021 15:19:00 +0200") Message-ID: <86fsquucte.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> > This whole discussion started from a request to be able to accumulate >> > messages in the echo-area so that the user who is away could see them >> > all when he/she comes back from whatever took him/her away. There >> > could be quite a lot of messages accumulated during that period, and >> > the request was to leave them all on display. For which you proposed >> > to use clear-message-function in a way that doesn't actually clear >> > them. >> > >> > Is the above an accurate description and summary of what is being >> > proposed here? If so, is it now clear what kind of job I think >> > display of echo-area messages was never designed to support? >> >> Thanks for explanation, now it's clear where is the misunderstanding. >> >> Actually, the patch for clear-message-function here is unrelated >> to the feature that uses set-message-function to accumulate messages >> and doesn't use clear-message-function. >> >> The feature here is intended for users who want to always leave >> the last displayed message in the echo-area, and never clear it. >> It will be possible even to do this conditionally. > > But if messages aren't cleared, they will accumulate, and then we get > to the problems I described. So it is not "unrelated", really. When the message is not cleared, it will be displayed until another message will replace it. This is unrelated to multi-message feature. > In any case, if this feature is unrelated, why do you want to have it > on the release branch? This is another misunderstanding. I didn't intend to have this on the release branch. But since you mentioned it, why not? Maybe better to apply the patch for clear-message-function on the release branch? From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Dec 2021 12:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, larsi@gnus.org, ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.163957209924096 (code B ref 40774); Wed, 15 Dec 2021 12:42:02 +0000 Received: (at 40774) by debbugs.gnu.org; 15 Dec 2021 12:41:39 +0000 Received: from localhost ([127.0.0.1]:60426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxTbH-0006GZ-Cq for submit@debbugs.gnu.org; Wed, 15 Dec 2021 07:41:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mxTbG-0006GN-3z for 40774@debbugs.gnu.org; Wed, 15 Dec 2021 07:41:39 -0500 Received: from [2001:470:142:3::e] (port=46816 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 1mxTbA-0005b0-F6; Wed, 15 Dec 2021 07:41:32 -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=0yfdiakE0eKWtneWpsWA77hbAgPI+QcJDYCci5k7GyA=; b=BnSB6Q+cpIka HPgGwvcdkUmODFN8UQmwfWvHmkisQDgxocnZlKYulwR+Yx+hfE5Brr8Tq18brbenFIznAuee+dMKF fV6S7+OaA6fWLYSL220AYlUdUpaCOHusE7q0PEMYtl/tNE2dbmMx9oE3EKlk+ve2oOcbxgDxkCyOW rsHkQupA4n1YD/zLwial9tIxv8n4mNCsfKijpRDn6ZgX+N3hH1kEIVKGXUxkkscjGKcjIlewAUFTu wUlmiu1Puuk/P5vGR3e8yW0cEeGofXfVBYyfrk4l6dc623F4r3Y13D8TBAfzm1HVtNgXAfM5xkJmq 9CJzvsVCyjG+AcdhBeSWUw==; Received: from [87.69.77.57] (port=3241 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 1mxTb8-0006F8-Hm; Wed, 15 Dec 2021 07:41:32 -0500 Date: Wed, 15 Dec 2021 14:41:11 +0200 Message-Id: <83a6h2jb14.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86fsquucte.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 14 Dec 2021 22:54:53 +0200) References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> <831r2gmox3.fsf@gnu.org> <86sfuwnxtv.fsf@mail.linkov.net> <83o85kl2aq.fsf@gnu.org> <86ee6f4mqe.fsf@mail.linkov.net> <83ee6fl3y3.fsf@gnu.org> <86fsquucte.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, 40774@debbugs.gnu.org, ndame@protonmail.com > Date: Tue, 14 Dec 2021 22:54:53 +0200 > > >> > This whole discussion started from a request to be able to accumulate > >> > messages in the echo-area so that the user who is away could see them > >> > all when he/she comes back from whatever took him/her away. There > >> > could be quite a lot of messages accumulated during that period, and > >> > the request was to leave them all on display. For which you proposed > >> > to use clear-message-function in a way that doesn't actually clear > >> > them. > >> > > >> > Is the above an accurate description and summary of what is being > >> > proposed here? If so, is it now clear what kind of job I think > >> > display of echo-area messages was never designed to support? > >> > >> Thanks for explanation, now it's clear where is the misunderstanding. > >> > >> Actually, the patch for clear-message-function here is unrelated > >> to the feature that uses set-message-function to accumulate messages > >> and doesn't use clear-message-function. > >> > >> The feature here is intended for users who want to always leave > >> the last displayed message in the echo-area, and never clear it. > >> It will be possible even to do this conditionally. > > > > But if messages aren't cleared, they will accumulate, and then we get > > to the problems I described. So it is not "unrelated", really. > > When the message is not cleared, it will be displayed until another message > will replace it. This is unrelated to multi-message feature. OK, then I guess it was a mistake to discuss this under this particular bug report. > > In any case, if this feature is unrelated, why do you want to have it > > on the release branch? > > This is another misunderstanding. I didn't intend to have this > on the release branch. But since you mentioned it, why not? Because we are done experimenting on the release branch. Only bugfixes should be installed there. From unknown Wed Aug 20 01:20:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40774: Error messages shouldn't be hidden when the user is idle Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Apr 2022 15:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40774 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 40774@debbugs.gnu.org, Eli Zaretskii , ndame@protonmail.com Received: via spool by 40774-submit@debbugs.gnu.org id=B40774.165072707131979 (code B ref 40774); Sat, 23 Apr 2022 15:18:02 +0000 Received: (at 40774) by debbugs.gnu.org; 23 Apr 2022 15:17:51 +0000 Received: from localhost ([127.0.0.1]:56998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHWB-0008Ji-Lz for submit@debbugs.gnu.org; Sat, 23 Apr 2022 11:17:51 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHW9-0008JV-NE for 40774@debbugs.gnu.org; Sat, 23 Apr 2022 11:17:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MUljlZUGb1bIf4C3g0A2Nc7qI3pZcUjAeeJA2VDPReM=; b=KmZqgzBaOwashwwofUSszr/Bqv mypANcfOkVjG08zhPWLgzDb/+DHkAj6vLPp8+DkaJMhtOXU7Fpp/aHhNxELeFQyxDqdbAB0BF5nyT LJIBaIq7YrVzKjh60okSuOxvh14e6TmYYJfA1Rqoia/WF/yeKcCi3JPDi7pEDyi3dENg=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1niHW0-0006iG-1I; Sat, 23 Apr 2022 17:17:42 +0200 From: Lars Ingebrigtsen References: <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> <8335n2x3w5.fsf@gnu.org> <865yrtiqb6.fsf@mail.linkov.net> <83wnk9mwmx.fsf@gnu.org> <86v8ztfuga.fsf@mail.linkov.net> X-Now-Playing: Arthur Russell's _Sketches For World Of Echo (June 25 1984 Live At Ei)_: "Changing Forest (Live 6-24-84)" Date: Sat, 23 Apr 2022 17:17:37 +0200 In-Reply-To: <86v8ztfuga.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 12 Dec 2021 22:18:29 +0200") Message-ID: <87y1zvesmm.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > I tried to find an existing DEFSYM in syms_of_xdisp, > but it seems there is no suitable symbol, so a new symbol > 'dont-clear-message' could be added to syms_of_xdisp. > This is a patch over the pr [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > I tried to find an existing DEFSYM in syms_of_xdisp, > but it seems there is no suitable symbol, so a new symbol > 'dont-clear-message' could be added to syms_of_xdisp. > This is a patch over the previous patch: Makes sense to me, so I've now pushed it (with some changes) to Emacs 29. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 11:18:00 2022 Received: (at control) by debbugs.gnu.org; 23 Apr 2022 15:18:00 +0000 Received: from localhost ([127.0.0.1]:57001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHWJ-0008K4-So for submit@debbugs.gnu.org; Sat, 23 Apr 2022 11:18:00 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHWH-0008Jq-P8 for control@debbugs.gnu.org; Sat, 23 Apr 2022 11:17:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LlQgLvyNK7aQqRPWkhp+VNKk1YihiuEHFwEd+OAm8r4=; b=oKy4bgzwoXkNR1tJGwRaoYkVTf FFW+PKl3NJuET4l4OzQTUfoWAanBJ5JNFBZDX+CC4nravj/MsN5hzkedwi5+L6KPfPFQ95HmrgFQF OPVR3d8A+lfkw41AjNWEumsBliUJW1d+ZN8QHEDLmZz6KJjS1qgbSCxq8Z6Hk8zIG2YY=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1niHWA-0006kw-65 for control@debbugs.gnu.org; Sat, 23 Apr 2022 17:17:52 +0200 Date: Sat, 23 Apr 2022 17:17:44 +0200 Message-Id: <87wnffesmf.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #40774 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 40774 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 40774 29.1 quit