Re: typeahead problem

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 8,  1:38pm, Bernd Eggink wrote:
} Subject: typeahead problem
}
}   read -q "REPLY?Yes or no: " && do_something
} 
} Now if "do_something" takes some time and you type at least one
} character in advance, 'read -q' behaves as if you are constantly typing
} 'n', until you consume the pending character by a normal 'read'. In
} other words, if you do NOT issue a normal read, EVERY following 'read
} -q' will behave as if you had typed 'n', until the end of the script.
} 
} Is there a rationale for this feature  (which I still consider a bug,
} because it makes 'read -q' nearly unusable, at least in scripts)?

Andrej has been telling you mostly the right things ...

On Dec 8,  6:54pm, Andrej Borsenkow wrote:
} As to why it is taken for "no" - imagine, you typed something _before_
} read -q, and that was not completely consumed - you definitely does not want
} some leftover "y" to remove your valuable files :) so it tries to play safe.

The getquery() function is called for the `rm *` check (the one DISabled
by `setopt rmstarsilent`) and for spell checking (`setopt correct`) as
well as for read -q.  In those cases, typeahead is considered undesirable,
and in the spell-check case zsh wants to leave it available in case the
user intended it as input for the command.  In the `rm *` case, on systems
that support ioctl(FIONREAD), zsh consumes all the typeahead before it
prints the query.

On systems that don't support FIONREAD, zsh always consumes one character.

The question is which of those two cases `read -q` should emulate.  The
decision made was to treat it like spell checking, leaving the typeahead
alone when possible so that other commands may consume it.  The way you
get the "always consume one character" behavior is to use

	read -k1 "REPLY?Yes or no: " && do_something

so having `read -q` available as an alternative that does NOT consume any
characters is more flexible.  The problem this leaves that there's no way
to emulate "consume typeahead" from a script (because all other reads are
blocking and wait for a newline).

On Dec 8,  4:01pm, Andrej Borsenkow wrote:
} Subject: RE: typeahead problem
}
} It is a "feature" of your particular OS. There is CLOBBERS_TYPEAHEAD define,
} that tries to correct this.

Unfortunately, CLOBBERS_TYPEAHEAD only applies when zle is setting up the
terminal with zsetterm(), which doesn't happen during getquery().

On Dec 8,  5:30pm, Andrej Borsenkow wrote:
} Subject: RE: typeahead problem
}
} I tried it here with 3.1.5 + patches. It looks, like ZSH takes the first
} character on the line and ignores the rest.
} 
} while read -q && sleep 10
} do
} echo YES
} done
} y <- cursor immediately springs to the next line
} yyyYES
}       ^^^ output by ZSH
} <- note newline
} YES
} 
} Only first 'y' from 'yyy' is taken. Is it what you've seen?

I see the following in a patched 3.0.5 and in both patched and unpatched
3.1.5:

zagzig% while read -q && sleep 5
while> do echo YES; done
y				<-- newline echoed immediately
yyyYES				<-- I typed yyy, YES echoed after 5 sec.
n				<-- echoed immediately after YES
zagzig% yyy			<-- typeahead now appears at the prompt

} Well, manual says "read -q reads only one character" so it is really
} confusing. Currently it "reads the line and takes the first character".
} Who's wrong - binary or manual?

On my system, at least, zsh does not consume the line, only the first y
of the four that I typed.  That agrees with the manual, except that the
manual doesn't discuss the typeahead behavior.

On Dec 8,  6:54pm, Andrej Borsenkow wrote:
} Subject: RE: typeahead problem
}
} The ultimate place to correct it is bin_read(); call
} getquery with last argument 1.

That would indeed change the behavior, but only when FIONREAD is supported.

On Dec 8,  6:39pm, Bernd Eggink wrote:
} Subject: Re: typeahead problem
}
} Hm, is there any reason to call getquery(x, 0) at all?

I think the choice to pass purge==0 was partly to get consistent script
behavior regardless of the availablilty of FIONREAD.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com