From: Anthony Heading <aheading@jpmorgan.com>
To: zsh-workers@math.gatech.edu
Subject: EOF in vared
Date: Thu, 10 Apr 1997 19:21:48 +0100 (BST) [thread overview]
Message-ID: <199704101821.TAA27218@gmp-etpres1.uk.jpmorgan.com> (raw)
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
next reply other threads:[~1997-04-10 18:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-04-10 18:21 Anthony Heading [this message]
1997-04-11 14:27 ` Zefram
1997-04-11 16:52 ` Bart Schaefer
1997-04-11 16:57 ` Zefram
1997-04-14 20:29 ` Anthony Heading
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199704101821.TAA27218@gmp-etpres1.uk.jpmorgan.com \
--to=aheading@jpmorgan.com \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).