Zsh Mailing List Archive
Messages sorted by:
Re: EOF in vared
- X-seq: zsh-workers 3070
- From: Zefram <zefram@xxxxxxxxxxxxxxxxx>
- To: aheading@xxxxxxxxxxxx (Anthony Heading)
- Subject: Re: EOF in vared
- Date: Fri, 11 Apr 1997 15:27:34 +0100 (BST)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <199704101821.TAA27218@xxxxxxxxxxxxxxxxxxxxxxxxxxx> from "Anthony Heading" at Apr 10, 97 07:21:48 pm
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:
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
Messages sorted by: