Re: 'edit-command-line' undesired behaviour

[Denis <d.griaznov@xxxxxxxxx>]

Ehh, sorry for spam, noticed another mistake in my reasoning.

Replacing '*vim*' with 'vim' is also a half-baked solution, because it
would prevent custom relative/absolute paths of Vim and additional
option arguments in 'EDITOR' from falling under the Vim glob, and it
would fall under the general '*' glob. This solves the problem of
executable names that include 'vim' as part of their name from being
forced into this case, but the cursor positioning behaviour would be
inconsistent. Therefore, need more advanced regex/globs to account for
this.

Removing these special cases for Vim and Emacs entirely seems like the
simplest solution for consistent and fool-proof behaviour.

On Tue, Feb 4, 2025 at 12:08 PM Denis <d.griaznov@xxxxxxxxx> wrote:
>
> Disregard this part please, I misread the code:
>
> > the user should be able to
> > set his own options as he sees fit, which is currently not the case:
> > for example, the Vim case implies that the user cannot set his own
> > options in 'EDITOR' variable, as '-- $1' is included in the final
> > 'edit-command-line' invocation.
>
> But the rest still stands.
>
> On Tue, Feb 4, 2025 at 8:47 AM Denis <d.griaznov@xxxxxxxxx> wrote:
> >
> > 'edit-command-line'
> > (https://github.com/zsh-users/zsh/blob/master/Functions/Zle/edit-command-line)
> > includes globs to specialise behaviour for Vim and Emacs:
> >
> > case $editor in
> > (*vim*)
> >   integer byteoffset=$(( $#prebuffer + $#lbuffer + 1 ))
> >   "${(@)editor}" -c "normal! ${byteoffset}go" -- $1;;
> > (*emacs*)
> >   local lines=( "${(@f):-"$prebuffer$lbuffer"}" )
> >   "${(@)editor}" +${#lines}:$((${#lines[-1]} + 1)) $1;;
> > (*) "${(@)editor}" $1;;
> > esac
> >
> > And these globs are just asking for trouble... I wrote myself a shell
> > script to enable '--remote-wait' functionality of Vim in Neovim; it
> > worked as 'GIT_EDITOR' etc, but it surprisingly didn't work with Zsh -
> > and that's how I came across this. The problem is that my executable
> > is called 'nvimr', and hence it falls under the '*vim*' glob in
> > 'edit-command-line'.
> >
> > I think that '*vim*' and '*emacs*' should be replaced with 'vim' and
> > 'emacs' to prevent messing with random executables; or maybe these
> > special cases should be removed entirely - the user should be able to
> > set his own options as he sees fit, which is currently not the case:
> > for example, the Vim case implies that the user cannot set his own
> > options in 'EDITOR' variable, as '-- $1' is included in the final
> > 'edit-command-line' invocation.