After editing a file in nvim, xplr is in either action mode or selected the file

[mrdgo]

What I did:

• Open xplr
• navigate to a file
• press :e to edit it with nvim
• ...
• in nvim: :q

What I expect:

xplr in default mode, i. e. waiting for input or navigation

What sometimes happens instead:

xplr either behaves, as if I pressed : or Space - so it either waits for an action key or selected the file, I edited.

Additional info

• version: xplr 0.14.4
• installed via paru
• config
• OS: Artix Linux

I'd love to give more details, but I can't even reliably reproduce this. If you don't understand, I can also record a video/gif :)

Kind regards, Maxim

[sayanarijit]

This is a known neovim issue. I'm keeping an eye on it.

[BachoSeven]

@sayanarijit I could open a new issue, but I noticed similar behaviours with the zoxide and fzf(made by you I believe), which, when selecting the entry from fzf, return to xplr in some undefined mode which drops to recovery(?) I am new to xplr, but I think it's a similar issue to this one

[sayanarijit]

@BachoSeven Wow this is new... I don't think it's related, but I could be wrong. Can you pls post more info like which terminal, OS are you using, Any custom shell or shell plugins, does it happen on other terminals/shells etc.?

[BachoSeven]

Ok so the terminal doesn't matter(tried two opposite ones, st and wezterm); shell also didn't change anything(tried bash and zsh), I attach a recording along with a screenkey capture of input keys:

https://0x0.st/-VU9.mkv

You can find my xplr configuration so far at https://github.com/bachoseven/dotfiles/tree/master/.config/xplr (didn't upload the plugins as submodules yet but the ones which are not commented are present on my system, pulled down this morning).

[sayanarijit]

I couldn't reproduce it. Let's try to catch the stdin inputs to see if we get any hint. For that, we'll use the xargs.xplr plugin. With the plugin setup with default bindings, type xm and run fzf or zoxide (without the placeholder {}). See if you get anything in the input prompt after returning to xplr.

[BachoSeven]

I do get an escape code upon pressing Enter: https://0x0.st/-V08.mkv

[BachoSeven]

(same thing happens on bash where I have little to no configuration)

btw I use Arch since you were asking about my OS

[sayanarijit]

Finally, reproduced it. The smaller fzf window gave me a hint it's probably some fzf customization.

Not sure which one, but one of the exported variables is causing the issue.

[sayanarijit]

Although, since it happens with both nvim and fzf (with customization), we might get similar issues from other tools as well.

Maybe we can research ways to improve how xplr handles stdin.

[maximbaz]

With a particular environment I can reproduce the issue consistently in kakoune editor, so if you have some ideas to test, I'm happy to test and confirm!

[sayanarijit]

Hey @maximbaz more info will definitely help. I tried kakoune and couldn't reproduce the issue. So the key might be in the particular environment you mentioned.

[maximbaz]

You can see some repro steps in https://github.com/romkatv/zsh4humans/issues/140 but I don't really expect you to install it all, the thing is I just have no clue where to dig deeper, what kind of tests to perform, what to look for... Is there something I could patch on xplr side, reproduce the issue and see what happens? Do you have a theory of what might be going on, how is xplr even able to steal input from another app?

[sayanarijit]

I was able to reproduce the same with the fzf.xplr plugin, using the following config:

require("fzf").setup{
  args = "--height 50%"
}

Let's see what --height does and how it relates to the other similar reported bugs.

[sayanarijit]

All I can say is that when we launch or close another program from xplr shell, they send some keys to stdin, generally escape sequences. xplr then reads those inputs assuming they are legit user key presses.

You can take a look at event reader and Call implementation.

This is the workflow:

Pause reading input from stdin > spawn a shell and execute the command > Resume reading inputs

So, if the shell or the command sends some keys to stdin, xplr reads them after it starts reading inputs.

Example garbage inputs (as captured using xargs.xplr):

nvim

]11;rgb:2121/2121/2121

fzf --height 50%

[1;1R

I was able to reproduce https://github.com/romkatv/zsh4humans/issues/140 in a docker container using the following steps:

docker run -e TERM -e COLORTERM -w /root -it --rm ubuntu sh -uec '
  apt-get update
  apt-get install -y zsh curl tmux
  sh -c "$(curl -fsSL https://raw.githubusercontent.com/romkatv/zsh4humans/v5/install)"'

# pc, standard, no tmux, zsh, all compact

apt-get install -y kakoune

echo 'z4h init || return' > ~/.zshrc

exec zsh

curl -L https://github.com/sayanarijit/xplr/releases/latest/download/xplr-linux.tar.gz -o xplr.tgz
tar -xzvf xplr.tgz

export EDITOR='kak -n'
echo bla > bla

./xplr

I captured a single space (`) and colon:usingxargs.xplr`.

[sayanarijit]

To capture the keys:

• Install xargs.xplr with default config.
• Type Xs (for nvim/kak) or Xm for fzf --height 50%
• Type the command from above.
• Use the application.
• Exit the application.

You should see the captured keys on the input bar of xplr.

[sayanarijit]

I think I figured it out. It's my fault. Damn, it's async again.

[sayanarijit]

Thanks for all your valuable inputs. They helped a lot.