From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: m.sujith@gmail.com, 30182@debbugs.gnu.org
Subject: bug#30182: Update
Date: Sat, 03 Feb 2018 10:03:57 +0100 [thread overview]
Message-ID: <5A757AFD.5040404@gmx.at> (raw)
In-Reply-To: <831si3crf2.fsf@gnu.org>
> 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
next prev parent reply other threads:[~2018-02-03 9:03 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-20 6:26 bug#30182: 27.0.50; Crash when doing mouse-over on modeline Sujith
2018-01-20 6:28 ` bug#30182: Update Sujith
2018-01-20 10:35 ` martin rudalics
2018-01-20 10:45 ` Sujith
2018-01-20 14:12 ` martin rudalics
2018-01-20 15:27 ` Eli Zaretskii
2018-01-21 2:15 ` Sujith
2018-01-21 3:39 ` Eli Zaretskii
2018-01-21 3:55 ` Sujith
2018-01-21 16:15 ` Eli Zaretskii
2018-01-21 18:29 ` Sujith
2018-01-22 9:15 ` martin rudalics
2018-01-22 15:09 ` Sujith
2018-01-22 17:37 ` Eli Zaretskii
2018-01-22 18:59 ` martin rudalics
2018-01-22 20:40 ` Eli Zaretskii
2018-01-23 18:44 ` martin rudalics
2018-01-23 19:53 ` Eli Zaretskii
2018-01-24 8:39 ` martin rudalics
2018-01-23 2:49 ` Sujith
2018-01-23 16:18 ` Eli Zaretskii
2018-01-23 17:07 ` Sujith
2018-01-23 17:25 ` Eli Zaretskii
2018-01-23 18:10 ` Eli Zaretskii
2018-01-23 18:45 ` martin rudalics
2018-01-23 19:51 ` Eli Zaretskii
2018-01-24 8:38 ` martin rudalics
2018-01-24 19:10 ` Eli Zaretskii
2018-01-24 20:05 ` martin rudalics
2018-01-23 18:44 ` martin rudalics
2018-01-23 19:59 ` Eli Zaretskii
2018-01-24 8:39 ` martin rudalics
2018-01-24 19:13 ` Eli Zaretskii
2018-01-24 20:06 ` martin rudalics
2018-01-27 8:26 ` martin rudalics
2018-01-28 0:53 ` Sujith
2018-01-28 8:26 ` martin rudalics
2018-01-29 5:13 ` Sujith
2018-01-29 10:04 ` martin rudalics
2018-01-29 15:50 ` Eli Zaretskii
2018-01-30 8:30 ` martin rudalics
2018-01-30 13:32 ` Eli Zaretskii
2018-01-31 9:31 ` martin rudalics
2018-01-31 14:43 ` Eli Zaretskii
2018-02-01 2:29 ` Sujith
2018-02-01 9:26 ` martin rudalics
2018-02-01 17:44 ` Eli Zaretskii
2018-02-02 8:28 ` martin rudalics
2018-02-02 8:37 ` martin rudalics
2018-02-02 16:00 ` Eli Zaretskii
2018-02-03 9:03 ` martin rudalics [this message]
2018-02-03 10:29 ` Eli Zaretskii
2018-02-04 10:01 ` martin rudalics
2018-02-04 18:21 ` Eli Zaretskii
2018-02-06 9:28 ` martin rudalics
2018-02-10 9:47 ` martin rudalics
2018-02-02 14:14 ` Noam Postavsky
2018-02-02 16:11 ` Eli Zaretskii
2018-02-03 9:04 ` martin rudalics
2018-02-03 10:30 ` Eli Zaretskii
2018-02-04 10:01 ` martin rudalics
2018-02-04 18:01 ` Eli Zaretskii
2018-01-29 15:53 ` Eli Zaretskii
2018-01-30 8:30 ` martin rudalics
2018-01-30 13:34 ` Eli Zaretskii
2018-01-31 9:31 ` martin rudalics
2018-01-31 14:44 ` Eli Zaretskii
2018-01-21 18:37 ` Sujith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5A757AFD.5040404@gmx.at \
--to=rudalics@gmx.at \
--cc=30182@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=m.sujith@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.