[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
- bug#30182: Update, (continued)
- bug#30182: Update, Eli Zaretskii, 2018/02/02
- bug#30182: Update, martin rudalics, 2018/02/03
- bug#30182: Update, Eli Zaretskii, 2018/02/03
- bug#30182: Update, martin rudalics, 2018/02/04
- bug#30182: Update, Eli Zaretskii, 2018/02/04
bug#30182: Update, martin rudalics, 2018/02/02
- bug#30182: Update, martin rudalics, 2018/02/02
- bug#30182: Update, Eli Zaretskii, 2018/02/02
- bug#30182: Update, martin rudalics, 2018/02/03
- bug#30182: Update, Eli Zaretskii, 2018/02/03
- bug#30182: Update,
martin rudalics <=
- bug#30182: Update, Eli Zaretskii, 2018/02/04
- bug#30182: Update, martin rudalics, 2018/02/06
- bug#30182: Update, martin rudalics, 2018/02/10