From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#30182: Update Date: Sun, 04 Feb 2018 11:01:03 +0100 Message-ID: <5A76D9DF.6040704@gmx.at> References: <87k1wdqc4q.fsf@gmail.com> <5A634E53.7010205@gmx.at> <87mv182bzk.fsf@gmail.com> <83a7x7sww6.fsf@gnu.org> <87efmj27d5.fsf@gmail.com> <83vafvqjbf.fsf@gnu.org> <87inbvxdz8.fsf@gmail.com> <5A65AB97.1030401@gmx.at> <87po62kk10.fsf@gmail.com> <831sih23rh.fsf@gnu.org> <5A663490.3050409@gmx.at> <87r2qh5lya.fsf@gmail.com> <5A6C37A7.2020309@gmx.at> <87r2qag5wp.fsf@gmail.com> <5A6D8947.5010207@gmx.at> <87d11t9ria.fsf@gmail.com> <5A6EF1A2.30904@gmx.at> <83lgggirzp.fsf@gnu.org> <5A702D36.6040302@gmx.at> <83po5rh3pu.fsf@gnu.org> <5A718CFA.2080408@gmx.at> <878tcdtpbk.fsf@gmail.com> <5A72DD44.3060104@gmx.at> <83lggceh9m.fsf@gnu.org> <5A742122.3090008@gmx.at> <831si3crf2.fsf@gnu.org> <5A757AFD.5040404@gmx.at> <83efm2bc3m.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1517738442 26944 195.159.176.226 (4 Feb 2018 10:00:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Feb 2018 10:00:42 +0000 (UTC) Cc: m.sujith@gmail.com, 30182@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 04 11:00:37 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiH5o-0005Fd-BH for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Feb 2018 11:00:12 +0100 Original-Received: from localhost ([::1]:57110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiH7p-0001Yc-Ld for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Feb 2018 05:02:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiH7e-0001Xg-UZ for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 05:02:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eiH7a-0003Wn-Ul for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 05:02:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48306) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eiH7a-0003Wj-Qv for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 05:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eiH7a-0005vH-GH for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 05:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2018 10:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30182 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30182-submit@debbugs.gnu.org id=B30182.151773847422700 (code B ref 30182); Sun, 04 Feb 2018 10:02:02 +0000 Original-Received: (at 30182) by debbugs.gnu.org; 4 Feb 2018 10:01:14 +0000 Original-Received: from localhost ([127.0.0.1]:56200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiH6o-0005u4-J3 for submit@debbugs.gnu.org; Sun, 04 Feb 2018 05:01:14 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:51526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiH6n-0005tr-3J for 30182@debbugs.gnu.org; Sun, 04 Feb 2018 05:01:13 -0500 Original-Received: from [192.168.1.100] ([212.95.5.118]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Me4Ly-1eMjp13Qje-00PyJ9; Sun, 04 Feb 2018 11:01:05 +0100 In-Reply-To: <83efm2bc3m.fsf@gnu.org> X-Provags-ID: V03:K0:gvd1p/Va5lMWbSmFZLvyVLem/JyUOks2SLuQlb4zqVzPqMrWUvQ /YedLZf26NE0trXYklbUPlFTMOHFW+ZIV4Y8EWC6IZOFQV05PAemRFVGrTBfsma6wbgNSd+ dHD28fMaNvBL4aUQHroB9MmeGYwvS6HwKGWlnNVPrd3EH6L6LJh06oKL5N46DRgQAxUndJr 4FMSevwhZaj49HnfZIW4g== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZhP0fP1LySI=:Ok5f4HoA/Js08gbgMFFN+T uC8Uzcdqw1A7Eta/dJK8xBImBXXrT8JVdp7mRhYPEBgFmqPJE3I777vhTXMhtxVx/b4dFzcSl 1mEMtMZFDhJU9OUUMbLfekFTktKEkFwKW/Xq04nq1YvjDQNA28kMv8wPYsRCi8jTDb+K+YIl3 PRBcO7ZTzfkwA7e1bBXMq58J3QFLkwhx0AgGCcLWi6XCqF1cVq4eFx4g1MxtnkYOJfZ52fjwu Dao4RBE6odTdPfNuYfd1GOWdMG4L9sROoGikReB8sZrcGiO+V007ogfBG6SxFFwcvBddJU6N3 PZkxKsCa63EuRMzNXKUcgzpDkm4uHI/McfnBQqncraXYTQphgd+nA++0a5YFQR3q9GCDd3/Kl y5gMER5OR16A6/RzF1yoSS94eDC64qARKgrHQwEujBox1c59QfbNNMSf5tsGV2I86ywO36IyO 6PpFpYSDpDLxIbRTiup8wv6OSQycIIVmjZGwjoa08vmLFKHSgQ+5HxjneA9JIeXC79k7NjBFi qNab8pDqtnOeFCv5NxSBxpuelRMKrC+T/psF+iwi7EAO0AJ++Rer9VU2bkhPeakXIpIWtno5Z HImTT95HgpMjDx4OapAVv4J6XMaqea5XICq/2agddDwK9lqjNJRL/s7LRdbunYVEG7BXKWzB9 81UToerz8hG5jAQMcrOrGXl6Nbd5+CSpTYeAguc8YpW5zBGrfaF1Igss5tguzBFoCHQtwmgwn M0RBYzSkOeAKhnjNXOBNDppsEUXxOMRhAP02CP2LP9sc+DKg3stecy8mZ6TnmNfwwkh3aDh3 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:142880 Archived-At: > That commentary was outdated. I updated it now. Thanks. > Please take a look > and tell if anything there needs clarification or any other change. One question I'd ask myself is how we avoid that redisplay is reentered during maybe_quit. And I would like to know which settings can disrupt redisplay and whether and which, if any, parts of redisplay (mode lines and echo area) may get through after such a disruption, probably to avoid garbling the display. > I believe that what I wrote in the message to which you were replying > was based on incorrect interpretation of what actually happens. With > the correct interpretation, there's no asynchronous entry into > redisplay, if "asynchronous" is interpreted literally. So the > measures I described above are unnecessary, but there is a need to > block input around C fragments that cannot tolerate changes in global > state. I must admit that I never thought of maybe_quit being able to process input when a function like 'copy-sequence' executes "normally". Maybe this should be emphasized in the Elisp manual's section on Quitting. I don't even understand what it's good for to process input just after a few conses or calculating the length of some short list. > This now raises the question: should we block input around the 2 calls > to Fcopy_sequence in timer_check, on the emacs-26 branch? I tend to > think we should, because letting arbitrary Lisp change the timer lists > while Fcopy_sequence runs could cause hard-to-debug bugs. WDYT? It cannot possibly harm so I think we should. >> And one thing that is obviously needed is some guidance on what should >> be allowed in the mode line and what should be avoided. For example, >> having `mode-line-buffer-identification' install a timer is something >> that should be avoided IMO. > > If we protect Fcopy_sequence as indicated above, I think such a > limitation would no longer be necessary. If the :eval form in 'mode-line-format' changes an arbitrary list which is about to be copied, a similar crash could be provoked. Or am I missing something? martin