Zsh Mailing List Archive
Messages sorted by:
EOF in vared
- X-seq: zsh-workers 3068
- From: Anthony Heading <aheading@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: EOF in vared
- Date: Thu, 10 Apr 1997 19:21:48 +0100 (BST)
I'd like to use `vared x' in a script in place of `x=$(/bin/cat < /dev/tty)'.
This is for "Enter a log message" type applications, e.g. RCS checkin.
** Two small points first
1) vared is a bit overenthusiatic with accept-line. Easily circumvented by
wrapping it in a script a la zed(), of course, but a multi-line mode
would be useful natively - e.g. vared -m x.
2) what is the justification for not allowing vared to create variables unless
given a -c flag? Isn't this just a tedious regulation?
** The main point
zle_main basically treats EOF as an error. This is a bit unfair:
% vared -c h
% echo $?
As an experiment, I turned off eofchar recognition when in_vared was set
(I think Zefram's renamed this, of course, but I'm behind the times a bit)
and created a new function which I bound to ctrl-D inside zed().
if (cs != ll || cs != findbol())
done = 1;
So typing ^D on an empty final line exits vared. This works just fine,
except for a slightly ugly extra linefeed which appears for probably obvious
But how best to implement this properly? Implicitly assuming that EOF is
the same key as delete-char is rather ugly. Thinking aloud, a pragmatic
alternative is just to forcibly hardwire an
if (in_vared && c == eofchar && cs == ll && cs != findbol()) done = 1;
type of test into zle_main. Would that upset anyone? Do the new widget
things (or whatever they're called) offer a more flexible alternative?
Regardless, I think I'd like to suggest that an `in_vared' variable is
reintroduced, and distinguished from `allow_history_access' or whatever the
new variable was more sensibly renamed. Maybe bitmasks on one variable?
I'll keep playing - zle is great, and it's a pity not to make it more
Messages sorted by: