search

vifm / vifm.vim

Vim plugin that allows use of vifm as a file picker
333 stars 19 forks source link

Visual jitter? #20

Closed ghost closed 5 years ago

ghost commented 5 years ago

When I switch to vifm, I can see the terminal emulator -- especially the command vim - which was used to open vim -- for a split second (almost non-noticeable).

Is there a way to prevent this visual jitter? dirvish for example doesn't do this. I don't know if it is because of :terminal's behavior or something else like spawning a new program? If so I am not sure if it can be done in a better way.

xaizek commented 5 years ago

dirvish operates within vim. You can see the terminal here, because that's how vim works by hiding its interface and then running another process on :!cmd.

:terminal isn't actually used by default in non-graphical vim, to force it set

let g:vifm_embed_term = 1

in your vimrc file. With this previous state of the terminal shouldn't appear.

ghost commented 5 years ago

Thank you so much @xaizek.

There is a small problem (for my OCD :smile:) when I use :terminal.

I have this mapping: <leader>e to EditVifm.

When I switch to vifm using <leader>e and exit using Esc, I can't immediately do <leader>e because it needs one extra click to work. Even my other mappings like s bound to :write doesn't work; it almost feels like my custom mappings are not restored until I do some operation. Does this happen to you?

This doesn't happen with dirvish, non-emedded version of vifm or when I do :terminal ++close vifm. I am just wondering if there something is missing in the way vifm "comes back" ?

It works f I add the following code at the end of VifmExitCb. But it feels very hacky:

call feedkeys("<esc>")

If there is no other way, I can send a PR.

xaizek commented 5 years ago

I see the same weird behaviour. I don't really know what might be causing it. It looks as if Vim needs to visit event loop to realize that window isn't a terminal anymore and restore bindings, but I'm not sure how to check for this if the state is actually restored the moment a key is pressed.

ghost commented 5 years ago

Oh, so should I just send a PR with the hack? I hope :call feedkeys ("<esc>") doesn't cause any harm!

xaizek commented 5 years ago

call feedkeys("\<esc>", 'n') is better. You can send a pull request, but I'll need to think if this should be addressed by the plugin or just in Vim.

ghost commented 5 years ago

Okay here is the PR. I used "Workaround" instead of "Fix" in the commit message :smile:

Let me know if you find the real problem! If it is a vim issue, then I think it needs to be reported upstream.

ghost commented 5 years ago

@xaizek , shall I close the PR (not this issue) as this is only a temporary workaround? Will wait for a proper fix hopefully in Vim.

xaizek commented 5 years ago

I didn't get to debug it and if it's a Vim's bug, it at least needs to be reported before waiting for it to be fixed.

xaizek commented 5 years ago

Can you still reproduce it? It looks like I can't. It doesn't seem to be caused by the plugin, because I can't reproduce it on version from April. However, I did upgrade Vim since than and now using 8.1.1583. If you can reproduce it, what's your version of Vim?

ghost commented 5 years ago

I am able to reproduce this in Vim version 8.1.1694. It is not caused by the plugin because it works in Neovim. I can remove the PR; I guess it is a small bug in Vim's terminal emulator somewhere?

xaizek commented 5 years ago

Thanks for testing. let g:vifm_embed_split = 1 in my configuration prevented it from happening, so it's still there. I'll try to look into it a bit.

xaizek commented 5 years ago

I found vim/vim#3522 bug report, which is what we're seeing here and sent vim/vim#4683 which tries to fix it.

ghost commented 5 years ago

Thank you @xaizek . Appreciate! I will go through these PR's and try to understand what is happening! I'll remove the MR -- the details are here anyway if anyone wants this quick hack.

xaizek commented 5 years ago

The change got applied in 8.1.1703. Does it work for you?

ghost commented 5 years ago

Yes, it works fine in 8.1.1703. What does ins_char_typebuf(K_IGNORE); do? I am just curious. I think I can close this PR!

xaizek commented 5 years ago

It inserts a fake character into buffer used for reading input. As I understand there is a separate loop for reading input in a terminal mode, the problem is that it does an extra iteration before exiting and this iteration consumes (somehow conditionally, as builtin mappings aren't affected) and throws away one character sometimes. Putting a fake character that doesn't mean anything fixes this.