fix: use :startinsert instead of feedkeys to switch to terminal mode
If user has their own startinsert, e.g. in the following case,
startinsert is trigger by :term, but later fzf term is focused.
nvim \
+"au TermOpen * startinsert" \
+"term" \
+"lua vim.defer_fn(function() vim.cmd [[FzfLua files]] end, 100)"
Technically user should not startinsert on an incorrect window, but
currently there's no way to avoid it since builtin startinsert seems
defered but nvim_get_mode is fast (return actual mode immediately).
This PR periodly retry and only do startinsert in nt mode and on fzf term buffer.
TODO: test
Idk if we should touch this part, every time I messed with this (tried different strats) some edge case blew up (quite a few issues… including voodoo slowness), if the OP is the only issue so be it.
https://github.com/ibhagwan/fzf-lua/blob/ea6d8ce0842c9a0d16587fcaaa75efe64e8c5695/lua/fzf-lua/fzf.lua#L225-L246
Idk if we should touch this part, every time I messed with this (tried different strats) some edge case blew up (quite a few issues… including voodoo slowness), if the OP is the only issue so be it.
Sometimes use lsp_incoming_calls (maybe it's slow?) from builtin picker, i is also inserted into prompt unexpectedly.
Another edge case(found just now): press <c-g> too quickly in live_grep then I will have this error (however I cannot reproduce it in mini.sh which also just insert i into prompt)
vim.schedule callback: Vim(normal):Can't re-enter normal mode from terminal mode
Generally I think feedkeys "i" in terminal mode is not a good way. Since it's possible that we are really in terminal mode (startinsert already happened for some reason).
Another way maybe simpler, cannot we just use buffer-local TermOpen to startinsert?
That's seems the recommanded way from document :h :term | /TermOpen:
To enter |Terminal-mode| automatically: >
autocmd TermOpen * startinsert
defer_fn hack here is just to avoid autocmd (maybe it's too complicated)
Another edge case(found just now): press
too quickly in live_grep then I will have this error (however I cannot reproduce it in mini.sh which also just insert i into prompt)
This never happens to me even if I continue holding ctrl-g forever and stop randomly.
Another way maybe simpler, cannot we just use buffer-local TermOpen to startinsert?
I’ve looked into many different methods, forgot why this one didn’t work, I’m willing to explore this again just know that this is somewhat sensitive and as of now nobody complains or has issues with it.
This never happens to me even if I continue holding ctrl-g forever and stop randomly.
I just found the root cause of the error is a bug of my another plugin... Now no problem in my config even with lsp picker. (Although I can still insert i in mini.sh with a high key repeat rate e.g. xset r rate 140 100).
Maybe leave it here until some report more bug.
I also implement inline screenshot (like nvim's screen:expect) in test suite. Not sure if this feature needed. I can split this out to another PR.
I also implement inline screenshot (like nvim's screen:expect) in test suite. Not sure if this feature needed. I can split this out to another PR.
I saw, looks great, if you are unsure about this PR and want the screenshots merged you can split it and I’ll merge.
@phanen, I rebased and removed the CI commit since we already merged that, would you like to explore this further?
I tested the autocmd for TermOpen, it has a drawback when starting a new picker while the buffer is open, for example:
FzfLua builtin, select any picker = picker starts in normal modeFzfLua live_grep+ctrl-g= normal mode
Wrap defer_fn can make it work. But would it be better to find another approach? I check some old issues e.g. it cause some laggy on wsl.
Wrap
defer_fncan make it work. But would it be better to find another approach? I check some old issues e.g. it cause some laggy on wsl.
TBH the current approach mostly works, I don’t know of any issues aside from what you wrote in the OP.