Re: zsh-3.1.2-zefram3

[Anthony Heading <ajrh@xxxxxxxxxxxxxxxxxx>]

On Mon, Jan 12, 1998 at 11:27:05AM +0000, Andrew Main wrote:
> I'd particularly like to discuss the recent ZLE-related feature patches:
> [...]
> N  3554 ajrh     allow vared to succeed on EOF
> 	This can be done by temporarily rebinding ^D to accept-line, or
> 	to a user-defined widget that conditionally calls accept-line.
> 	(See Functions/zed for an example of how to temporarily change
> 	bindings.)  Also, while I agree that vared -c is not much
> 	use, removing the option entirely will cause problems with
> 	some scripts.  Changing the default EOF behavior would cause
> 	similar problems.  While I would like the whole area of EOF
> 	handling in ZLE to be re-examined, this patch does not do a
> 	proper job of that.

Hmmm.  I'm not sure I understand quite what this means in practice.
Can we break it down?

PREMISE:
I would aver that the EOF char acting as accept-line is a natural
default (viz my original desire to emulate the RCS check-in input).

PRIMARY HANDLING OF EOF:
In zleread()

-           if (!ll && isfirstln && c == eofchar) {
+           if (c == eofchar && cs == ll && cs == findbol()) {
                eofsent = 1;
                break;
            }

I think that this is an improvement.  I think the condition has been
changed at least once already in the past year, but nobody discussed
it and nobody complained, so preservation of the status-quo may have
been demonstrated de-facto not to be an overriding imperative.

Does anyone find this problematic?  It's not difficult to make it
conditional on a vared flag, but Occam's razor advises not playing
silly buggers unless you need to.

VARED HANDLING OF -c:

Perhaps Zefram missed the fact that the patch retained the -c flag as
a null op?  The balance as always is cost (incompatibility) against
benefit (here simplicity).  I still suspect that the incompatibilty
is minimal: that no-one relies on that error condition in scripts.
But others may know better.  Not important - it was just a cleanup.

VARED HANDLING OF EOF:

If you like, we could swap the sense of the -e flag and keep the
current behaviour as the default.  

RE-EXAMINATION OF WHOLE OF ZLE EOF HANDLING:

I'd agree completely that this patch doesn't make a proper job of
anything like that.  I'm not sure what all the issues are.  It was
simply intended as a small step in the right direction

USE OF ZLE WIDGETS:

This is probably the point where I become unhinged.  At least in the
environment where I work, flexibility in user-space configuration is
absolutely no substitute for a satisfactory default.  And in the area
of multi-line zsh editing, zsh has a little tweaking still to do
before that default is reasonable.


Nu chto zh.  Zefram: I think the only necessarily incompatible change
is the tweak to zleread().  Is that objectionable?  All the others
can be reworked to preserve the current behaviour as default, if that
what you think is appropriate.  If the problem is more that you don't
want to see eof handling touched until it's radically overhauled, I
think you'll need to clarify what needs done.

Anthony