EOF in vared

EOF in vared

[Anthony Heading]

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

Re: EOF in vared

[Zefram]

Anthony Heading wrote:
>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.

I've been considering adding variant keymaps for multiline mode.
One would have multiline and single-line versions of `viins', `vicmd'
and `emacs' keymaps.  It could be done most conveniently with another
new feature I was considering, that would allow a keymap to act as if it
were a copy of some other (named) keymap but with some arbitrary changes.
One could have, for example, a multiline `vicmd' keymap looking like:

	"^J" down-line-or-history
	"^M" vi-down-line-or-history
	"ZZ" accept-line
	otherwise behave like the single-line `vicmd'

Another possibility would be to allow each keymap to have a number of
these `filters' associated with it, and a global setting would determine
which of these variants of each keymap selected would actually be used.

>zle_main basically treats EOF as an error.  This is a bit unfair:

A possibility that I'd like is to have it somehow distinguish between an
EOF return and an accept-line return, and let the caller decide whether
it's an error.  A switch on vared would allow it to accept EOF returns.

>As an experiment, I turned off eofchar recognition when in_vared was set

in_vared is not set when the vared -h option is used.

>                                                       Do the new widget
>things (or whatever they're called) offer a more flexible alternative?

They could.  A possibility is to have an eof widget, which by default
would cause a failing return, but could be redefined to call accept-line,
or to delete a preceding newline and then call accept-line, or something
else.

-zefram

Re: EOF in vared

[Bart Schaefer]

On Apr 11,  3:27pm, Zefram wrote:
} Subject: Re: EOF in vared
}
} I've been considering adding variant keymaps for multiline mode.
} 
} Another possibility would be to allow each keymap to have a number of
} these `filters' associated with it, and a global setting would determine
} which of these variants of each keymap selected would actually be used.

How will you fill your free time after you finish reimplementing emacs?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

Re: EOF in vared

[Zefram]

Bart Schaefer wrote:
>How will you fill your free time after you finish reimplementing emacs?

I'm planning to re{design,implement} Unix, from the design principles up.
Watch out for it in ten years or so.

-zefram

Re: EOF in vared

[Anthony Heading]

Zefram wrote:
> I've been considering adding variant keymaps for multiline mode.
> One would have multiline and single-line versions of `viins', `vicmd'
> and `emacs' keymaps.  It could be done most conveniently  [...]

Excellent.

> A switch on vared would allow it to accept EOF returns.

OK.  I might try to implement that unless you get there first.  Should the
default be to allow them?

> >As an experiment, I turned off eofchar recognition when in_vared was set
> 
> in_vared is not set when the vared -h option is used.

Yup.  That's why I suggested creating two flags, one for vared, the
other for history availability.

Cheers

A