Zsh Mailing List Archive
Messages sorted by:
Re: zsh exits suddenly.
- X-seq: zsh-workers 4164
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: zsh exits suddenly.
- Date: Thu, 25 Jun 1998 10:33:12 +0200
- In-reply-to: ""Bart Schaefer""'s message of "Wed, 24 Jun 1998 09:17:12 DFT." <980624091713.ZM4823@xxxxxxxxxxxxxxxxxxxxxxx>
"Bart Schaefer" wrote:
> On Jun 24, 10:51am, Peter Stephenson wrote:
> } Subject: Re: zsh exits suddenly.
> } I can't be absolutely sure if all that lastc stuff is really needed.
> } It means, of course, that if there is more than one line in the
> } buffer, only the current one is flushed. Is this the right behaviour?
> This isn't changed by your patch, right? It was the behavior all along?
Yes, this was exactly all it did before during an interactive read:
discard everything up to the next newline.
> The guideline should probably be, what does ZLE
> do to a multiline buffer when send-break is executed? The SIGINT handler
> ought to do the same thing. (In fact, why doesn't it call sendbreak()
> when ZLE is active?)
Actually, at the zle stage there shouldn't be any line input to flush
yet, so this doesn't really matter (i.e., after my last fix
inerrflush() always becomes a no-op here, regardless of the lastc
behaviour), but for what it's worth the complete multi-line buffer is
discarded in both cases.
The proper use of inerrflush() is when lexing the line just input.
I've found the difference: it's in a case like this:
% print !!:s/foo/bar/<ESC><RET>
The current code gives an error message for the substitution (assuming
of course there was no `foo' in the previous line), but prints `haha'
anyway. Without the lastc stuff, the `print haha' is discarded along
with the rest of the previous line.
Oddly, the code for "event not found" and for "Ambiguous history
reference" performs the effect of inerrflush() itself, i.e. reading up
to a newline: this may well be just an oversight from before
inerrflush() was written.
So the question boils down to: after a history subsitution failure,
should the rest of the input be discarded, or just the rest of the
line as at present? (Note parsing failures don't flush the input in
any case, i.e.:
% if [[<ESC><RET>
will always print `haha' after some error messages. It also has an
extremely funny effect on the history lines stored.)
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx> Tel: +39 50 844536
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy
Messages sorted by: