bug#16804: 24.3.50; [PATCH] fix with-silent-modifications

[Leo Liu]

On 2014-02-20 22:01 +0800, Stefan Monnier wrote:
> Actually, the issue is not with with-silent-modifications but with
> sit-for and other yielding functions: you should be careful to call them
> from within the "plainest" context possible, since any dynamic-binding
> (or other temporary global change, such as moving point) currently active
> will then leak to any timer/filter/sentinel/redisplay that might be run
> at that point.

OK for now.

>> Since input-pending-p is changed in 24.4 not to run timers by default,
>> the backtrace is obtained in 24.3 and as expected:
>
> Ah, right, input-pending-p shouldn't be a yield point, which we recently
> fixed, so it should be OK to call input-pending-p from "anywhere".
>
> Can you reproduce the problem in 24.4 (and show the backtrace)?

No. I tried but cannot get any backtrace in 24.4 so input-pending-p is
behaving.

>> nxml has both input-pending-p and sit-for, see
>> rng-validate-while-idle-continue-p in rng-valid.el
>
> Indeed, I see
>                  (with-silent-modifications
>                    (rng-do-some-validation-1 continue-p-function))))
>
> where continue-p-function can be rng-validate-while-idle-continue-p
> which calls sit-for (to cause a redisplay).  So we have a similar bug there.

How about replace (sit-for 0) with (not (input-pending-p)) in
rng-validate-while-idle-continue-p?

>> Is there something better than let-binding buffer-file-name and
>> buffer-file-truename?
>
> I have the patch below for 24.5 which makes it unnecessary for
> with-silent-modifications to bind buffer-file-name and
> buffer-file-truename (by strengthening the meaning of
> inhibit-modification-hooks), but that doesn't magically fix the above
> problems :-(
>
>
>         Stefan

Thanks for the fix.

Leo