Another one from last May.

On Fri, May 22, 2020 at 3:24 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The patch implements "zed -h" which loads the history into vared and
> arranges to replace the existing history with that before it exits.
> This does NOT solve Markus' complaint about the history numbers, they
> increase by the number of entries output by the editor. It makes no
> attempt to account for various history options, so those may change
> the final result if they affect "print -s".
>
> It also handles "zed -h filename" which loads that file and saves it
> back again rather than alter the current shell history.

On Tue, May 26, 2020 at 8:32 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I think zed has a long-standing problem with SH_WORD_SPLIT and
> probably some other SH_ options?
>
> % setopt shwordsplit
> % zed "/tmp/one two"
> Where does this go?
> % cat "/tmp/one two"
> cat: '/tmp/one two': No such file or directory
> % cat /tmp/one
> Where does this go?
> %
>
> So ... how far do we go to make "zed" compatible with nonstandard
> options, and how do we approach doing it?  Try to use entirely
> portable syntax, or invoke "emulate -L", or something in between?
> Look at the handling of function names, too -- it creates the empty
> function definition with ${(q-)1} but makes no attempt to quote $1
> when calling "functions" or "autoload".

The attached patch both implements zed -h and fixes issues with
SH_WORD_SPLIT and NO_SHORT_LOOPS, but does not attempt a comprehensive
repair, so the "how far do we go?" question remains.  Completion is
updated per Oliver's advice in the "_arguments optspecs" thread
(starts at workers/45909, messages from Oliver seem to have been
doubled up in the archives) but could use a once-over.  Doc also
updated.

A minor head-scratcher for me (insufficient note-taking to return to
this a year later) is that at one time the code for zed -h was using
  var=( "${(@Oav)history:gs/\\/\\\\}" )
before invoking vared.  Now I can't figure out when or why I thought
that was necessary; I'm able to edit my existing 500 commands / 734
lines of history without seeing any garbled backslashes, using only
  var=( "${(@Oav)history}" )
as in the patch.  Can anyone jog my memory?  Do backslashes ever need
double-escaping?