Temporary insert mode - Githubissues

kana / vim-submode

Vim plugin: Create your own submodes

http://www.vim.org/scripts/script.php?script_id=2467

217 stars 24 forks source link

Temporary insert mode #14

Open LFDM opened 10 years ago

LFDM commented 10 years ago

Feature proposal mentioned in #13

This has been talked about in #1 already (btw, hi again @suy) and is relatively easy to implement. I'd say this makes only sense when you invoke it from a normal mode submode anyway, so I didn't try it for any other modes. I implemented a submode#temporary_insert_mode function, meant to be the rhs of a mapping as in submode#map('submode', 'n, '', 'i', ':call submode#temporary_insert_mode()<cr>' The function leaves the current submode, enters insert mode and defines an augroup that holds an aucmd triggered by the InsertLeave event which reenters the submode that has just been left. The reenter function clears the aforementioned augroup again, so that we aren't left with any deadweight afterwards.

kana commented 10 years ago

There are many commands to shift to Insert mode. i, a, c, s, and so on. Additionally, users might have their own key mappings to shift to Insert mode. Is the proposed method really feasible?
InsertLeave is not reliable. It will never be triggered by <C-c>.
What should happen if a user uses i_CTRL-O?

LFDM commented 10 years ago

I think if you need to call c or anything more complex yoiu might be better of with leaving the submode regularily. i or a would be no problem, a user would define define the mapping inside the submode and we could invoke insert mode with the same key (user maps a to enter the temporary insert mode, which is invoked with a then.
I wouldn't mind about <c-c> I think it's bad practice to rely on <c-c> for leaving insert mode, as there are quite a few plugins that define InsertLeave events - you break them all with <c-c>
i_CTRL-O is a problem, but this might also call for the user's sanity. If he wants to do anything complex, he'd be better off leaving the submode and reentering again.

To me a fast way to reenter the last submode (#15) would probably solve the need for this entirely and would provide a very fluid workflow.

kana commented 10 years ago

First of all, submodes are never sticky by design. Submodes are like Visual mode on Normal mode. Like vlllcbar<Esc>, once a user shifts to another (major) mode, the previous submode will never be restored automatically even if the user backs to the previous major mode. So that I won't support sticky submodes.

I think if you need to call c or anything more complex yoiu might be better of with leaving the submode regularily. i or a would be no problem, a user would define define the mapping inside the submode and we could invoke insert mode with the same key (user maps a to enter the temporary insert mode, which is invoked with a then.

What commands are "complex"? It depends on users' tastes. And some commands preserve the last submode while other commands don't so? It's totally inconsistent.

LFDM commented 10 years ago

FYI these issues are just thinking out loud, I am in no way insistent on these features. Especially this issue is indeed probably just a bad idea and not really useful.

For the sake of argument, of course it depends on the user's taste: It would be the responsibility of the user anyway to define such special mappings. There should be no sticky mode by default at all, the general behaviour of submode is just fine. But giving users the chance to customize things is a good thing, it's their decision after all what they want to do.

I'll gladly close this issue again, as I agree that it's a little bit overboard and a too opinionated feature.

I still think it would be a good idea to have an API for setup/teardown (#16) and entering/leaving (#17). Such an interface would provide a user with all the tools he needs to do quite a lot of things with submodes - whatever it is he wants to do then is totally his decision. It would even be easy then to implement (the admittedly stupid) temporary insert mode, or the fast reentering proposed in #15.