Spawning $EDITOR gives an error on windows+msys2/zsh

[doronbehar]

Hi,

I'm using lf on msys2, with the mingw-w64-ucrt-x86_64-lf package, and msys2/zsh. My $XDG_CONFIG_HOME/lf/lfrc has:

set shell zsh
# Do as explained here: https://github.com/gokcehan/lf/wiki/Tips#split-words-by-default-in-zsh
set shellopts '-e:--shwordsplit'
# I use lf also on Windows msys2, and this has to be used with the above shell.
set shellflag "-c"

And I get this error when I press e to spawn an editor:

zsh:fg:1: no job control in this shell.

Which makes sense I guess on this system, but I am not sure I understand why job control is needed, and how lf exactly requires it. I tried as a workaround to use nvim-qt.exe with:

map e !nvim-qt<space>$f<enter>

And got:

zsh:1: parse error near `>'

And with:

map e &nvim-qt<space>$f<enter>

I got nothing opened...

[CatsDeservePets]

First things first: I don't have experience with msys2. Are you using the Windows or Linux version of lf?

I see you are using <space> and <enter> in your map command. This is not necessary.
What happens if you use the following: map e $nvim-qt "$f"?

[doronbehar]

First things first: I don't have experience with msys2. Are you using the Windows or Linux version of lf?

I installed lf with:

pacman -S mingw-w64-ucrt-x86_64-lf

Which is built with this expression.

What happens if you use the following: map e $nvim-qt "$f"?

Launches fine! Still not ideal though - I wish I could stay in the same terminal and not open a new window.

[CatsDeservePets]

Launches fine! Still not ideal though - I wish I could stay in the same terminal and not open a new window.

I remember having problems like this with Windows in general when executing .py or .bat scripts and stuff like that. Perhaps someone with more knowledge about Windows can help us here.

I will move this to the discussions as we are now talking about configuration rather than bugs inside lf.

[doronbehar]

BTW, there's a similar experience with claude-code: When I run it inside tmux inside zsh (both from msys2/ package repository of msys2), the app completely exits when I try to edit a prompt with the default $EDITOR (which is nvim). However if I use it outside of tmux, nvim launches fine.

[doronbehar]

I managed to fix this (while not hurting the Unix config), with:

map e $$EDITOR "$f"

Very peculiar why it is needed to be set explicitly on Windows for it to work. It works inside & outside tmux (no equivalent behavior to what's observed with claude-code).

@gokcehan since the above is supposed to be the default, and it doesn't work well on Windows, could you please convert this back to a bug report?

[CatsDeservePets]

I managed to fix this (while not hurting the Unix config), with:

map e $$EDITOR "$f"

If your $EDITOR env var is set to nvim-qt, it should not make a difference whether you use map e $$EDITOR "$f" or map e $nvim-qt "$f".

Very peculiar why it is needed to be set explicitly on Windows for it to work. It works inside & outside tmux (no equivalent behavior to what's observed with claude-code).

@gokcehan since the above is supposed to be the default, and it doesn't work well on Windows, could you please convert this back to a bug report?

The reason for this happening is that all MinGW tools and packages are Windows binaries. Build constraints like //go:build !windows and checks for runtime.GOOS still determine your OS being Windows, not Linux. Therefore, lf uses different keybindings:

lf/doc.md

Lines 376 to 403 in 230ef16

	The following commands/keybindings are provided by default:
	Unix
	cmd open &$OPENER "$f"
	map e $$EDITOR "$f"
	map i $$PAGER "$f"
	map w $$SHELL
	cmd help $$lf -doc | $PAGER
	map <f-1> help
	cmd maps $lf -remote "query $id maps" | $PAGER
	cmd nmaps $lf -remote "query $id nmaps" | $PAGER
	cmd vmaps $lf -remote "query $id vmaps" | $PAGER
	cmd cmaps $lf -remote "query $id cmaps" | $PAGER
	cmd cmds $lf -remote "query $id cmds" | $PAGER
	Windows
	cmd open &%OPENER% %f%
	map e $%EDITOR% %f%
	map i !%PAGER% %f%
	map w $%SHELL%
	cmd help !%lf% -doc | %PAGER%
	map <f-1> help
	cmd maps !%lf% -remote "query %id% maps" | %PAGER%
	cmd nmaps !%lf% -remote "query %id% nmaps" | %PAGER%
	cmd vmaps !%lf% -remote "query %id% vmaps" | %PAGER%
	cmd cmaps !%lf% -remote "query %id% cmaps" | %PAGER%
	cmd cmds !%lf% -remote "query %id% cmds" | %PAGER%

This is not a bug, that is just the way things are. Using WSL2 with the real Linux version of lf should avoid this issue.

On a side note, Gökçehan is not really involved in the development of lf (he only ever publishes releases these days). You are better of tagging @joelim-work or me for things like that.

[doronbehar]

On a side note, Gökçehan is not really involved in the development of lf (he only ever publishes releases these days). You are better of tagging @joelim-work or me for things like that.

Oh sorry, didn't notice. Thank you for being responsive in general :).

If your $EDITOR env var is set to nvim-qt, it should not make a difference whether you use map e $$EDITOR "$f" or map e $nvim-qt "$f".

BTW I managed to use EDITOR=nvim too here, not only nvim-qt - there's no interactivity or fg support issue here.

The reason for this happening is that all MinGW tools and packages are Windows binaries. Build constraints like //go:build !windows and checks for runtime.GOOS still determine your OS being Windows, not Linux. Therefore, lf uses different keybindings:

lf/doc.md

Lines 376 to 403 in 230ef16

	The following commands/keybindings are provided by default:
	Unix
	cmd open &$OPENER "$f"
	map e $$EDITOR "$f"
	map i $$PAGER "$f"
	map w $$SHELL
	cmd help $$lf -doc | $PAGER
	map <f-1> help
	cmd maps $lf -remote "query $id maps" | $PAGER
	cmd nmaps $lf -remote "query $id nmaps" | $PAGER
	cmd vmaps $lf -remote "query $id vmaps" | $PAGER
	cmd cmaps $lf -remote "query $id cmaps" | $PAGER
	cmd cmds $lf -remote "query $id cmds" | $PAGER
	Windows
	cmd open &%OPENER% %f%
	map e $%EDITOR% %f%
	map i !%PAGER% %f%
	map w $%SHELL%
	cmd help !%lf% -doc | %PAGER%
	map <f-1> help
	cmd maps !%lf% -remote "query %id% maps" | %PAGER%
	cmd nmaps !%lf% -remote "query %id% nmaps" | %PAGER%
	cmd vmaps !%lf% -remote "query %id% vmaps" | %PAGER%
	cmd cmaps !%lf% -remote "query %id% cmaps" | %PAGER%
	cmd cmds !%lf% -remote "query %id% cmds" | %PAGER%

I read that and I understand (I am familiar a bit with Go development), but what is the difference between map e $%EDITOR% "$f" on windows and map e $$EDITOR "$f" on Unix? I claim this is a bug because whether lf is launched from MSYS2's zsh or from a powershell terminal, with EDITOR=nvim (assuming it is found in $PATH in both shells), it should act the same.

[CatsDeservePets]

I read that and I understand (I am familiar a bit with Go development), but what is the difference between map e $%EDITOR% "$f" on windows and map e $$EDITOR "$f" on Unix? I claim this is a bug because whether lf is launched from MSYS2's zsh or from a powershell terminal, with EDITOR=nvim (assuming it is found in $PATH in both shells), it should act the same.

The difference is the syntax used for variable expansion. cmd syntax won't work when using zsh (or PowerShell).
Another thing I don't know is to what extend MSYS2 inherits your Windows environment variables. I'd imagine at least $PATH being modified before passing them to lf.