How to disable t/T and f/F overrides?

[augustocdias]

I'm generally fine with the idea of what they do but they make the . stop working or making it with really confusing behavior.

I use a lot cf<CHAR>, replace the text, next occurrence and . and lightspeed just breaks that flow. I would like to be able to disable those overrides and have only the jump with s/S which is what this plugin is most useful for me.

[ggandor]

they make the . stop working or making it with really confusing behavior.

Could you elaborate? If they do not work with . like the native f/t, then please raise an issue instead, because it is a bug then. But I'm not experiencing any such problems.

[augustocdias]

Wouldn't it be better to have an option in the setup to disable this? I'd be willing to help with a PR

[ggandor]

I don't use packer, but couldn't it be that packer is somehow set to automagically lazy-load lightspeed, on some event?

If all else fails, you could just map something (unused) to the <plug> keys instead, before sourcing lightspeed (that will prevent lightspeed from creating the corresponding mappings):

map <a-s-f9> <Plug>Lightspeed_f
map <a-s-f10> <Plug>Lightspeed_F
" etc.

[ggandor]

Wouldn't it be better to have an option in the setup to disable this? I'd be willing to help with a PR

#11

It would imply a breaking change, because calling setup() would then be mandatory for everyone who want the default keymaps. And I consider such requests - i.e., not wanting to use f/t or s/x at all - exceptional, so I'm not too keen on providing this feature as a built-in option.

I understand that a few users will always have exceptional needs, and that's totally OK, but as I wrote in the above linked thread,

The assumption is that the default mappings are sane and carefully thought out, and 95% of the users want to use the provided features as they are. The others could do some extra mileage I guess.

[augustocdias]

Why would it be mandatory if you make all enabled by default?

[ggandor]

Just think about it: if we map the keys by default, i.e. without needing to call setup(), it means that we do that unconditionally when sourcing the plugin, so setting a flag via setup could make no difference. All we could do is to unmap the already mapped keys in that case.