bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30182: Update


From: martin rudalics
Subject: bug#30182: Update
Date: Sun, 04 Feb 2018 11:01:03 +0100

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]