Re: 'edit-command-line' undesired behaviour

[Denis <d.griaznov@xxxxxxxxx>]

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.