On Tue, Sep 1, 2015 at 4:04 PM, Eli Zaretskii wrote: > > Date: Tue, 1 Sep 2015 15:14:09 +0000 > > From: Pip Cet > > Cc: 21380@debbugs.gnu.org > > > > (* - well, one segfault. But I attribute that to extraordinarily bizarre > > actions even by my standards: attempting to display an unprintable ASCII > > control character in the echo area. > > Is this reproducible? If so, please submit a separate bug report with > a recipe. > #21394. > > > Usually this is fine because propertized strings never end up in the > > echo area (I hope)...) > > The echo area is a normal buffer, so any face can be used in it. See, > for example, the message printed by info.el after "i SOMETHING RET". > Thanks for explaining! You're right, then, it's a bug. > That only prevents us from reading new events from the X socket, but > what if some signal that is already pending invokes some Lisp? I don't understand. How can we call "some signal that is already pending" (I'm not sure what that means. A unix signal? Or just something that sets pending_signals to a true value? Or an atimer?) when input_blocked_p () is true? The only thing gobble_input () does in that case is store_user_signal_events (), which doesn't call any Lisp. The only code path that I see that's potentially dangerous is that atimers appear to be executed even if input is blocked.