From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@euclid.skiles.gatech.edu>
Received: (qmail 18263 invoked from network); 10 Apr 1997 18:25:31 -0000
Received: from euclid.skiles.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 10 Apr 1997 18:25:31 -0000
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id OAA04187; Thu, 10 Apr 1997 14:18:57 -0400 (EDT)
Resent-Date: Thu, 10 Apr 1997 14:18:57 -0400 (EDT)
From: Anthony Heading <aheading@jpmorgan.com>
Message-Id: <199704101821.TAA27218@gmp-etpres1.uk.jpmorgan.com>
Subject: EOF in vared
To: zsh-workers@math.gatech.edu
Date: Thu, 10 Apr 1997 19:21:48 +0100 (BST)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"o-lZR3.0.J11.FyIJp"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3068
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

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