On 6/26/12 3:51 AM, Max Horn wrote:
>> They key is that the hook needs to be run after the check for already-read-
>> and-queued input, and it should only be run if rl_gather_tyi doesn't
>> detect any input available. That was the issue with bash-4.1/readline-6.1:
>> the input hook got run for every input character, whether anything was
>> available or not, making it very hard to use it as something that got run
>> after a specified timeout, for instance.
>>
>> Here's a patch against bash-4.2. Applying it to a standalone readline
>> installation is left as an exercise for the reader. :-)
> Thanks! Solved the exercise, too ;).
>
> But I am puzzled a bit by this patch: First, this new code
>
> while (rl_event_hook)
> {
> ! if (rl_get_char (&c) != 0)
> ! break;
> !
>
> is just a different way of saying
>
> while (rl_event_hook && rl_get_char (&c) == 0)
> {
>
> Well, I guess it's a matter of taste whether to use the first or the second.
I think it makes the code read more clearly.
> What surprises me is the second change: You also added a "continue" in case
> "rl_gather_tyi" did manage to read something. So this would reduce the number
> of times the event hook is being called. So I assume this is meant to fix an
> issue distinct from the one I reported, respectively to make the behavior of
> this loop conform with the expected behavior you just described (only calling
> the hook if a rl_gather_tyi completed with a *full* timeout, no data was
> read). Correct?
Yes. The reason the change was made in the first place is that the hook
should not be called for each character read. That's not its purpose, and
it makes using the timeout more difficult.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-readline mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-readline
