system() polluted by CursorShape termcodes with iTerm2 + tmux + fish

[kozie]

• nvim --version: 0.2.0-1
• All other variants of Vim (even neovim 0.2.1-dev or older version than 0.2.0-1) seem to work
• Operating system/version: MacOS 10.12.5
• Terminal name/version: iTerm 3.1.20170724-nightly
• $TERM: xterm-256color (using tmux)

I know it's weird to post the issue over here since i only seem to have an issue with this one plugin but since it only occurs on a particular neovim version (0.2.0-1) it's hard to say it's the plugin being the problem.

When running the command :GFiles from (fzf.vim) i get the following error:

Error detected while processing function fzf#vim#gitfiles[6]..<SNR>63_fzf[18]..fzf#run[76]..<SNR>20_execute_term:
line   55:
E344: Can't find directory "^[Ptmux;^[^[]1337;CursorShape=0^G^[\/Users/koos/Development/fiftiesstore-m2" in cdpath
E472: Command failed
Error detected while processing function fzf#vim#gitfiles:
line    6:
E171: Missing :endif

See my original issue.

[justinmk]

Try disabling 'guicursor'. Do this by setting it to nothing:

:set guicursor=

I don't know why this would interfere with fzf, it seems like <SNR>20_execute_term is scraping pty/terminal jobs instead of pipes. @junegunn what does s:execute_term do differently than, say, the tmux strategy used for vim? Does fzf try to filter out termcodes? https://github.com/junegunn/fzf/blob/a2604c0963caf458fdd46fe0f83fcd2cc6388582/plugin/fzf.vim#L628

[kozie]

Disabling the guicursor option didn't change anything. Thanks for the effort though.

[justinmk]

By "didn't change anything" you mean the error message is still:

E344: Can't find directory "^[Ptmux;^[^[]1337;CursorShape=0^G^[\/Users/koos/Development/fiftiesstore-m2" in cdpath

What does :verbose set guicursor? say?

[kozie]

Sorry for the lack of information. The error is still the same indeed.

Strange thing though. I removed neovim HEAD (brew remove neovim) and installed the latest released (0.2.0-1) to test the guicursor option with above result. Now switched back to neovim HEAD and the same error occurs using GFiles.. This is starting to get pretty weird though.

:verbose set guicursor? gives the following in both neovim 0.2.1-dev & 0.2.0-1:
guicursor=n-v-c-sm:block,i-ci-ve:ver25,r-cr-o:hor20

[justinmk]

What is :verbose set guicursor? after disabling it and trying fzf ?

[kozie]

I Started neovim, did :set guicursor=, then :GFiles, then :verbose set guicursor? and it gave me:
guicursor=

[kozie]

Seeing the term 'tmux' within the error i thought "Hey, let's test this without tmux" and it works though. That is probably what i did this morning with neovim 0.2.1-dev. So i updated tmux but it didn't solve anything. I might check my tmux configuration now but still, neovim still seems the only vim variant having this problem, probably because of the terminal.

[DarkDefender]

Do you set or use cursor colors? IE hi Cursor guifg=black guibg=green gui=reverse
That is the only place I can see that we use the Tmux wrap codes for iterm...

[kozie]

No, i don't have any of these gui settings you mentioned. You can view my dotfiles here.

I tried disabling/removing the gui settings in my vimrc i have there right now but it doesn't change a thing. Of course i sourced and restarted neovim just for insurance ;)

[justinmk]

neovim still seems the only vim variant having this problem, probably because of the terminal.

Fzf doesn't use Vim's built-in terminal yet, so it is not comparable.

[DarkDefender]

Does it work if you use bash instead of fish?

Edit: For everything that is. So fish is not used at all in fzf

[junegunn]

@justinmk There's nothing extraordinary. And GFiles is basically this:

git -c color.status=always status --short --untracked-files=all | fzf --ansi

[kozie]

well, it has to do something with tmux since it only happens in that environment but i don't know what it is.

looking at this line i presume that tmux is adding something to a command that fzf fires
E344: Can't find directory "^[Ptmux;^[^[]1337;CursorShape=0^G^[\/Users/koos/Development/fiftiesstore-m2" in cdpath

edit
I Changed the default terminal setting in tmux from screen-256color to xterm-256color and it seems to work for now. I think i can live with this. Thanks for the effort all.

[DarkDefender]

@kozie Did you try it with bash? I think that it might be something with fish also.
This because to me it seems like neovim would never print CursorShape=0 for iterm. We would print descursor code like \x1b[3 q instead. And the place were we would use the tmux wrap, it would not print a sequence like the one you got.

So to me it seems like there is something else that is trying to influence the cursor shape by trying to send codes to iterm. iterm supports two ways of doing this. Either with the widely adoped descursor standard or with its own codes that looks like konsole cursor codes.

However, tmux only supports the descursor codes. That is, it knows what to do with them and tries to do the right thing (only have the cursor changed on the pane the code is sent from). It doesn't understand the other code though. So to be able to use it and not have tmux eat it, you can wrap the code in the special Ptmux terminal code. However with that, tmux can't keep track of the cursor shape so it will change on all panes.

Can you please try it with bash to see if your shell has anything to do with this? It would be nice to hunt down what is printing that specific code (and as i said before, I don't think it's neovim).

[kozie]

I haven't tried bash yet but i think i will later today. It seems @junegunn also found another issue that seems related and also seems to be caused by fish. I might try the suggestion given there disabling the vi mode cursor and report back here.

also, i agree that it doesn't seem to be neovim problem at all.

[kozie]

Sorry for the late response. Had quite the busy week so not much room to do some testing for this.

What i tested for now is the following:

• Restored the terminal used by tmux to screen-256color instead of the aforementioned xterm-256color
• Configured tmux to use the default terminal bash (also for reattach-to-user-namespace)
• Start tmux through bash, open vim in a git project and do :GFiles
• Start tmux through fish, open vim in a git project and do :GFiles

The above all seemed to work like it should.

I also tried the suggestion in the issue i mentioned in my previous message by adding the noop functions to my config.fish but that didn't fix the issue.

[justinmk]

Looks like a configuration issue.

[cmollekopf]

Had the exact same issue for ages (with a variety of other stuff also breaking such as opening of commits via :Gblame) without a solution.

Finally found a workaround over here (turns out it can be fixed via the fish shell config): junegunn/fzf#881 (comment)