Re: a bug of read-passwd

[Chong Yidong <cyd@stupidchicken.com>]

Richard Stallman <rms@gnu.org> writes:

> One solution is to set up a mechanism for the sit-for timer
> to determine that it has been called inside a filter.
> Then it needs to be able to set up for a certain function to be
> called when the filter returns.
>
> Another solution would be, don't use a timer.
> read-event works by calling wait_reading_process_output.
> It should be feasible to give it a new argument
> which specifies a maximum time delay.

OK, I looked into this.  I think that fixing read-event to give it a
new argument specifying a max delay turns out to be not simple to
implement.

(The detailed situation is this: the old sit-for called
wait_reading_process_output for a given duration, but that's
problematic since wait_reading_process_output can return due to fake
events.  The new sit-for solves this by calling read-event, which
relies on read_char, which loops calling wait_reading_process_output
with zero duration and discarding fake events [using
kbd_buffer_get_event, which does some complicated processing to figure
out if the event is fake or not].  The new sit-for interrupts this
loop using a timer.  If we want to hack read_char to accept a new arg
specifying the max delay, there would be two sets of timing code:
inside read_char, and inside wait_reading_process_output.  This is
very inelegant.)

Another possibility is to implement a `inhibit-timers' variable and
set it to t by default inside filter functions (similar to how
`inhibit-quit' is bound to t in filter functions.)  This is probably
easier to implement.  What do you think?