Re: EOF in vared

[Zefram <zefram@xxxxxxxxxxxxxxxxx>]

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