Re: zsh-3.1.2-zefram3

["Bart Schaefer" <schaefer@brasslantern.com>]

On Jan 18,  3:14pm, Anthony Heading wrote:
} Subject: Re: zsh-3.1.2-zefram3
}
} 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.

This is true, but seems clumsy especially because the EOF char is normally
overloaded as delete-char-or-list.  You'd be forced to write a user-defined
widget that implemented `delete-char-or-list-or-eof' to make it work right.

On the other hand, I don't believe that vared *should* behave the way that
typing text into `cat` would.  Vared is not a streaming editor; I expect
it to behave like an editor that controls my terminal, not like a process
blindly reading from standard input.

} 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).

I would aver that there shouldn't *be* any recognized EOF char in vared,
just as there is no EOF in vi or emacs.  That is, as best I can tell, the
current behavior.

} 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.

How exactly does this change the behavior, again?  EOF on any empty line
is EOF, even in a multiline edit?  Yes, I object to that.  I want EOF to
be EOF when typed on an empty line at a PS1 prompt, and nowhere else.

} 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.

The condition changed from 3.0.2 to 3.0.3, adding the "&& isfirstln".
That was sometime before 27 June 1997.  I don't know exactly what that
accomplished.

} 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.

Scripts are not the only case to consider; I dislike having my interactive
habits disrupted, too.  In this case, this wouldn't bother *me*, but ....

} VARED HANDLING OF EOF:
} 
} If you like, we could swap the sense of the -e flag and keep the
} current behaviour as the default.  

That would be preferable.

} 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.

I agree completely.

} Nu chto zh.

What?

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