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: Sat, 03 Feb 2018 10:03:57 +0100 Message-ID: <5A757AFD.5040404@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> 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 1517648601 26425 195.159.176.226 (3 Feb 2018 09:03:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 09:03:21 +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 Sat Feb 03 10:03:16 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 1ehtj7-0006MV-Nq for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Feb 2018 10:03:13 +0100 Original-Received: from localhost ([::1]:60038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehtl7-0008Hk-5Q for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Feb 2018 04:05:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehtkt-0008FO-7B for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 04:05:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehtks-0005rW-AU for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 04:05:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47015) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ehtks-0005rN-7Q for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 04:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ehtkr-0002Cr-QI for bug-gnu-emacs@gnu.org; Sat, 03 Feb 2018 04:05:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Feb 2018 09:05:01 +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.15176486508394 (code B ref 30182); Sat, 03 Feb 2018 09:05:01 +0000 Original-Received: (at 30182) by debbugs.gnu.org; 3 Feb 2018 09:04:10 +0000 Original-Received: from localhost ([127.0.0.1]:54906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehtk2-0002BJ-4u for submit@debbugs.gnu.org; Sat, 03 Feb 2018 04:04:10 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:63124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehtjy-0002An-Ov for 30182@debbugs.gnu.org; Sat, 03 Feb 2018 04:04:07 -0500 Original-Received: from [192.168.1.100] ([213.162.73.116]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MBWIM-1eYW4H3eEw-00AXYf; Sat, 03 Feb 2018 10:03:59 +0100 In-Reply-To: <831si3crf2.fsf@gnu.org> X-Provags-ID: V03:K0:ItwESKvfsJ4C9EW8OBOOnHRrm6uSIBOld4NrE3mJK+0eKWCGE3Z oG80bllVgbHci52ayLqGwEQnxfIG44r0PmGMHjkV5ut6R4Da1cGnek6BtD4k14x7y9my74n wvfMzEdQgxr05frtF/a69M/g5L0fNfWLVLXu9pb7QzvJIree2NdO6yC2dOucGfvz3PAADTf bUGOIF6wBLIrD3VL0yoww== X-UI-Out-Filterresults: notjunk:1;V01:K0:zb7/oMAeyVY=:hGSHfhUBMu8+h6JT3Q8kzT D+lx3zY7nfUWX99DNEO6zCF9XS+BChb1J1YcbdC+DiI4SiYf2sg1A+z6QF+QvbECWOLgxhUvH 2+QMeITaVqF1MibyQhbvlrPcUrvw09u8xJlyxaxGG4a2sAX8QRsQWjhVtUwLEZaAPUTWPlCa8 9eNS1Y22OSh7KNLbefkHXb5VLthbUqrp3msInmSD8IDXkF/Iln0/QxLaxMAH+6RZDGuIf0G4A Csz0TocoIpB5gvxsfWckkhQrtMF6fcU+0yOFuyBfYPh6h5DD5x/1PeBUTUioDDRR7kOMaRTzZ dElTohCT9Iu/9YZO0iUqVdKScXT3OEW4dJU6pvfXHrBETFdIhLFACzYTtcEkOhmsqUjDfOMwe aT6eGvhQzn+pCdbttz/M8DY0L2DsPL99J4FE3b3XF0otEb3EC9tSy6CemuREnvh7IBcN7hUFE PYitUs16jHdh7KR1XUPTpzfukJYVu9Zq5Wj/HD3R1O8hDxoybAXadmfMf3xGXGfJJburEm3da BnkEtJxC545bvMId/7lHiOVvljlxMZS8hyIm8pVe1x8pthXDIJp0WnBGuirjlS6j83TsacM1h ZpQFd+88/jDkDgYu++s+VcheWX0z469M4L27eE2+H7AqVyQzz793mNINV7jEpNqtEc6Frgk9C nOnOcpFa26++Hi/Q2OqFtlB+CBiVgvhymfxKShJGM3myoNmOn2oYoglbpPb+uQSX0AURppN1Q z4LTv0VgCGZN2ItE35jLd7yaP3oYi8y4nEe1yuAfJeca60isZJwkjHc1gWyVYKov0z2h096h 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:142837 Archived-At: > But I think the problem introduced by this recent change, which allows > Lisp to be called asynchronously, is a much more serious problem than > just timer_check. This recent change was only an amendment to a fix of Bug#16647. There I changed the shape of the mouse cursor, here the accompanying tooltip. So anything that goes wrong now should have gone wrong then already. But for one thing: The present changed introduced that call to `window-in-direction' which clearly is a bad idea for the mode line because it may want to get the height of the mode line while building the mode line string and thus introduce infinite recursion. I don't know why that didn't happen here in the first place. For the interested - try to display the value returned by (posn-at-point) in the mode line. > We _cannot_ call Lisp asynchronously in any safe > way. I'm afraid we will have to roll back the change which allowed > mode-line-default-help-echo to be a function. Can you find an > alternative way of achieving the same effect, that doesn't call Lisp > from note_mode_line_or_margin_highlight? I could do that easily. But IMO the problem is not with calling Lisp per se. We frequently call Lisp fnctions from C. The problem is with altering the global state (`timer-list' being part of that) IIUC. > I think we should introduce some protection against making such > implementation mistakes in the future. Like some flag that we set > when redisplay is entered asynchronously, and that is checked in > safe__call, where we'd signal an error (or maybe even abort, under > "--enable-checking") if the flag is set. This should allow us to find > such problems much faster. WDYT? I'd need to see the problem identified first. The comment in xdisp.c says that Under window systems like X, some portions of the redisplay code are also called asynchronously during mouse movement or expose events. It is very important that these code parts do NOT use the C library (malloc, free) because many C libraries under Unix are not reentrant. They may also NOT call functions of the Lisp interpreter which could change the interpreter's state. What is an "asynchronous call" and how can I identify it? How do I avoid using the C library? How do I avoid calling functions of the Lisp interpreter? 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. martin