EOF in vared

[Anthony Heading <aheading@xxxxxxxxxxxx>]

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
[type ^D]
% echo $?
1

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

deletecharoracceptline(void)
{
    if (cs != ll || cs != findbol())
        deletechar();
    else
        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
reasons.

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
generally applicable. 

Anthony