option to disable all default mappings?

[alok]

I would rather just bind keys as lua functions

[ggandor]

See :h lightspeed-custom-mappings, :h lightspeed-disable-default-mappings, :h <Plug>, :h using-<Plug>. <Plug> keys are for exactly this purpose, they are aliases for the Lua function calls.

TLDR: nmap {preferred-key} <Plug>Lightspeed_s, etc., for the given modes (or the equivalent via the Lua API). (Note that you should do this in your config before the plugin is loaded. Also, make sure to use nmap, and not nnoremap here.)

In case you have any problems, I'll help you further.

[alok]

but those require mapping keys to something. i only want this for a single key, with all others inaccessible.

On Sat, Jun 19, 2021 at 3:00 AM György Andorka @.***> wrote:

See :h lightspeed-custom-mappings, :h lightspeed-disable-default-mappings, :h , :h using-. keys are for exactly this purpose, they are aliases for the Lua function calls.

TLDR: nmap {preferred-key} Lightspeed_s, etc., for the given modes (or the equivalent via the Lua API). (Note that you should do this in your config before the plugin is loaded.)

In case you have any problems, I'll help you further.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ggandor/lightspeed.nvim/issues/11#issuecomment-864384770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7QUTC3KADEZT273EONAR3TTRTENANCNFSM466UIOMQ .

[ggandor]

I see. Well, now that you can even map custom keys to repeat f/t (so ; and , can be used), this should be a very uncommon request - why install the plugin in the first place then? (If you have some other plugin that remaps these keys - let's say, for some reason you'd like to use clever-f to do f/F/t/T search -, then Lightspeed will not overwrite those, if you keep the right order.) So the only case when you would want to explicitly disable the default mappings is when you do not want to use a particular feature of Lightspeed at all, and you want the default Vim behaviour for the given key preserved. For the moment, I don't want to introduce a global variable solely for this - I think those few users can go through the negligible trouble of doing something like

map <C-M-S-F11> <Plug>Lightspeed_s
map <C-M-S-F12> <Plug>Lightspeed_S

that will effectively disable the s/S mappings, for example.

[stevearc]

FWIW, this was also my first request upon installing the plugin. I use s all the time and instantly looked for a "remove default keybindings" option to pass to setup(), as that's a pattern I frequently see with plugins. I agree that mapping it to a different key doesn't sound like much effort, but it doesn't work as expected (at least for me). I was putting my configuration inside of plugins/lightspeed.lua:

vim.api.nvim_set_keymap('n', '<leader>j', '<Plug>Lightspeed_s', {})
vim.api.nvim_set_keymap('n', '<leader>k', '<Plug>Lightspeed_S', {})

require'lightspeed'.setup{}

And while this does set up <leader>j/k to trigger lightspeed, it does not remove the binding froms. If I instead put this in a lua block in my .vimrc it works as expected. I think a setup option would be a simpler mental model and would be greatly appreciated 🙂

[ggandor]

@stevearc If you don't want to put that into .vimrc, before the Plug section, then all you have to do is adding these two lines to the lua config, to get your native s/S back:

vim.cmd('unmap s')
vim.cmd('unmap S')

I could provide such an "unmap" function, that does nothing more than the above, looping through all the default keys in all the modes, and skipping when they are mapped to something custom.

I don't know how other plugins usually do this, but if I'm not missing something, we cannot provide an opts option (that could be set with setup), because the plugin is already sourced by that time, and the mapping commands have been run. And I want to provide the default mappings, for a nice out-of-the-box experience, so that the user does not have to do anything, even calling setup, except for adding that one line to their plugin manager's list. (By the way, there's no need to call setup, only if you'd like to change something.) We could add a global flag of course, but that would be the only one, and feels inelegant.

aerial.nvim seems pretty cool by the way, not too bloated or convoluted, I will definitely check it out.

[rktjmp]

I wonder if you could change this:

https://github.com/ggandor/lightspeed.nvim/blob/cbc56c6390fa90e37f25ac45aec1d5ac29407679/plugin/lightspeed.vim#L7

to

lua require'lightspeed'.setup()

Users who do not want default mappings can set their plugin to load on-demand (I think most plugin managers support this), and then they can then manually bang the setup func:

Plug 'ggandor/lightspeed.nvim', { 'on': '__some__fake__thing__that_never_gets_called' } " see cond or similar in packer.nvim

require("lightspeed").setup({automap: false})
-- i guess this wont run any other viml in autoload, if you ever put something in there.

By default the plugin get's autoloaded and setup as it is now, and people who don't want the default maps bypass the default autoload and force it themselves.

Not sure, haven't experimented, I may misunderstand how those on-demand options work, I have never used them, maybe autoload still runs.

[stevearc]

@ggandor yeah if you want the out-of-the-box experience to be fully-featured with no configuration then I guess you'd have to either read a global var (which could still have initialization ordering problems) or provide that automatic unmapping function, potentially incorporated into setup. I tend to think that most vim users would want to customize any plugin they add, but I'm biased by my own preferences and probably overestimating. I can respect the choice to optimize for zero-configuration and minimal API surface.

I like the design so far! It's definitely a step up from EasyMotion.

[B4rc1]

FWIW, this was also my first request upon installing the plugin

same here, what lead me directly to this issue. Right now, i'm using the workaround you suggested, but it would be really sweet, to either have an example in the help page for how to restore native f/F or even better, separate variables in setup.

Something like map_f which would default to true, and control the remapping of f and F. Same for s/S and t/T.

[ggandor]

@rktjmp I'm not sure this is any simpler than adding one line of unmap f | unmap F | unmap t | unmap T after loading... (Also, note that the setup function has nothing to do with adding the mappings, as of now , that simply happens in the main body of the script.)

@B4rc1 May I ask why you woud like to restore the native f/F? I mean, the plugin does exactly what the native command does, and more. Even dot-repeat works. If it is because of the macro issue, then I understand your problem, but we should't make API changes for an otherwise exceptional case, just because currently there is a bug, that will hopefully be resolved in the future.

I will update the relevant sections of the help file though, with examples and more verbose explanations.

[B4rc1]

I want native f/F and t/T for macros that operate on multiple lines with variable amounts of matches. If i have this:

a, b, c,
d, e, f
g, h

i, j

and now want to put a new line after every comma for every line except the last I would record a macro a: f,a<CR><ESC> and then a macro b: @a@aj and runb for every line. With the lightspeed f, the macro would jump to the last line and add a newline there too, with native f, the macro stops at h, because it cannot find any more matches on the current line.

This is for macros only, but I use a lot of macros and for me, if I wanted the lightspeed f behaviour, I would just use lightspeed s as it does effectivly the same thing but in a more general way. I feel it changes the use case and Identity of f/F shifting away from a single line navigation command onto an general way of getting around near the courser in your file. I feel like for that, s/S is just perfect, thus for me, lightspeed f/F is obsolete.

Of course that's just me and I understand, that lightspeed f can be attractive for some people, but I prefer the safety in native f/F and t/T of not running macros, where I don't indent them to run. ""'Removing""' a native feature without an easy way to disable it is to me a bit intrusive. Of course you can disable it by remapping it to a different key (you will probably never use anyways if you dislike the feature), but to me that feels like a hack and disproportionally much effort, namely searching the help page explicitly instead of being presented the option up front in the configuration part of the plugin readme, just to leave a native vim feature alone.

I would make a pull request myself, addressing this, but unfortunately I'm not too familiar with fennel and lisps in general, just a bit elisp here and there for emacs and thus don't feel comfortable hacking together a solution, that just kinda works.

TL;DR: Native f/F and t/T for safety in macros as they stop macros if they don't find a match on the current line. An explicit Option would be nice, as it, to me, makes the plugin feel less intrusive.

[rktjmp]

@rktjmp I'm not sure this is any simpler than adding one line of unmap f | unmap F | unmap t | unmap T after loading... (Also, note that the setup function has nothing to do with adding the mappings, as of now , that simply happens in the main body of the script.)

Yeah, my point was may be a manner you could support people having their own "at boot" configuration without actually having to pick up the additional maintenance of supporting it if you didn't want to add a global guard or similar (which always feel pretty ugly to me). More of a "Here's an escape hatch if you want to do something off the rails".

There would still be a refactor as you say to wrap in add-default-mappings and some different option handling. I would argue that having it happen explicitly, whether wrapped in a setup function or otherwise aids testability and extensibility over implicit calls during require, and to most users they won't notice the change.

[ggandor]

@alok @stevearc @rktjmp @B4rc1 Okay, thanks very much for the input. I think we should just expose/document the add-default-mappings function then, that is already available. I will sleep on this.

@B4rc1 Good point about macros, not shortcutting on the current line could be a problem indeed, that has not occurred to me yet.

[ggandor]

@B4rc1 check #14

[liujoey]

I really love the sS mapping but I prefer to use the original ft, I use vim-plug but when I do unmap f at the end of vimrc, I get the error "no such mapping" it seems vim-plug didn't load lightspeed or at least not at the end of the vimrc, my work around is just to map f f | map F F | map t t | map T T but it is ugly. I would rather have an option in lightspeed to disable the 1-char feature.

[ggandor]

@liujoey If the problem is the error message, you can use silent! unmap .... (Btw. map f f | map F F | map t t | map T T is also perfectly nice, short workaround IMO.)

Also, what is your main reason for using native ft? I'd like to get input, so that we can improve the feature.

[liujoey]

Hi, just to answer your question, I don't mean my preference is better than anyone or what so ever, I'm just trying to describe how my muscle memory works.

I'm so used to type f then spam , for repeating. Sometime when I type the wrong char after f, i immediately type f or F again following by the correct char, my mind doesn't need to switch context between "oh this is the first f so it need a following char" or "oh this is the second f it will repeat previous one" or "oh I already started an f search now I need to quit it so I can start another f search", my brain just don't switch well on this set of keys.

Secondly, use sS for multi-line jump while ft for current line make sense to me, again it's about context switching, single line use ft, multi-line use s, don't need to think about it, just muscle memory.

I even use , and ; to repeat previous sS, this is one of the sneak's feature I like the most, but hey, your plugin has the best labeling mechanism I can't give up.

[ggandor]

Thanks very much for the reply!

Secondly, use sS for multi-line jump while ft for current line make sense to me, again it's about context switching, single line use ft, multi-line use s, don't need to think about it, just muscle memory.

Now this is a valid point, I've been thinking about this a lot too. The one remaining suboptimal aspect of this arrangement with f/F/t/T/s/S/x/X is that sometimes there's a grey zone between ft and sx where it's not immediately obvious which one would be the quickest. My own answer to this is that I always use s except when I'm totally sure that ft is the right one. I only use ft for operations or selections, when my target is either the first or the second match, and I can clearly see that. In any other case when I'm not sure about the context, just "oh, my eyes caught this target, I want to go there", even if it's close (maybe on the same line), I reach for sS, simple as that, because that's still quicker than any other method (and in most cases on par with ft, considering shortcut-labels and auto-jumping on partial input). But again, this is only my approach, not the one true way.

my brain just don't switch well on this set of keys

It would actually make sense to disable same-key repeat when custom keys are specified for instant_repeat_fwd_key and instant_repeat_bwd_key. I'm also planning to add a limit_ft_scope_to_current_line option. These together would provide enough flexibility, right?

I even use , and ; to repeat previous sS, this is one of the sneak's feature I like the most

Yeah, we've discussed that here, and I'd especially recommend reading this answer of mine. I don't know. Sometimes I still wonder though, would it make sense to allow s + ;, as shortcuts in smaller scopes for repetitive editing tasks, instead of relying on /?, *, and/or semantic analysis? Or that is indeed just a "bad habit" that should be unlearned... I'm not sure about the answer.

but hey, your plugin has the best labeling mechanism I can't give up.

I know, it's addictive... other plugins seem stone age after getting used to ahead-of-time labeling. :)

[liujoey]

Thank you for the detailed reply, i will give ft another try, by adding ,; to the repeat mapping. And thank you again for the great plugin!

[jaydorsey]

this should be a very uncommon request - why install the plugin in the first place then?

Lightspeed's X mode hijacks the x key in visual mode. In vim, the default is to delete a block/character when I have a visual selection.

Being additive with the keys, rather than having to subtract would be an easier transition into lightspeed for me as an nvim user (I'm not even sure what I map x to in visual mode to get the built-in behavior)

[rktjmp]

Being additive with the keys, rather than having to subtract would be an easier transition into lightspeed for me as an nvim user (I'm not even sure what I map x to in visual mode to get the built-in behavior)

To fix this you need to unmap x in x and o modes, which then reverts to default.

I agree I also found this pretty obtrusive. I have a years and years of muscle memory pressing x in visual mode, d synonym not withstanding. Having it "just break" one day because a (great) plugin updated was frustrating, especially when my initial "unmap x in v mode" didn't work.

[ggandor]

Lightspeed's X mode hijacks the x key in visual mode. In vim, the default is to delete a block/character when I have a visual selection.

That's true, but Lightspeed also hijacks s/S in the first place, and those do not even have a same-length alias (cl and cc, respectively). Whereas visual x/X is = d/D.

"(...) those keys are free in O-P mode, and are redundant equivalents of d/D in Visual mode; consider also the handy mnemonics, and the fact that s, z and x are physically right next to each other on a QWERTY keyboard."

We really cannot find a better alternative than this I think. For the breaking change, sincere apologies - if this makes it easier, I also have to fight with my own muscle memory, and learn to use d instead of x. :) @rktjmp I'm just curious, what keys are you using for x/X? Or you're not planning to use x-motion in Visual mode at all?

I'm actually open to remove the default mappings from Visual mode, and only map x/X for Operator-pending mode, that's where they are really useful anyway. That would make the arrangement more symmetric in fact (s/S for Normal and Visual, and O-P with its special inclusive/exclusive pair, z/x.)

On a general note:

For any other plugin, I would agree with the points raised by you folks. On the other hand, Lightspeed is not just another shiny toy on the list, but - according to my vision - aims to be an "enhanced native" or "new default" layer, a very organic extension, among the few plugins like targets.vim or surround.vim. It has an absolutey minimal, focused interface, that sharpens the saw in every respect, so to say, and is far from being a feature-creeper like EasyMotion et al. If e.g. some are not satisfied with the provided ft motions, then we should improve them, and/or make them even more flexible/configurable. I am continuously putting in the time and effort to polish the rough edges, fix compatibility and consistency issues with both core Nvim and the established ecosystem, and will continue to do so.

In such a case, zero-configuration setup might be a reasonable aim. Providing good defaults are very important for such a plugin. Most casual users do not touch them actually. 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.

Feel free to argue with me if you disagree with any of my points above, I'm totally open to discussion.

[jaydorsey]

In such a case, zero-configuration setup might be a reasonable aim.

I'm pro pretty much everything you're saying. I just think the experience should also be customizable. I actually don't want the s hijack either, because muscle memory.

What I'd really like is to do something like this:

  use {
    'ggandor/lightspeed.nvim',
    wants='vim-sandwich',
    config = function() 
      require('lightspeed').setup({disable_mappings = true}) 
    end
  }

vim.api.nvim_set_keymap('n', 'f', '<Plug>Lightspeed_f', {noremap = true, silent = true})

It's not that I might not grow into the other features, I just have one specific use case that I definitely want (a better, multi-line f replacement). I understand I may not be the target audience for lightspeed, but I have a couple years worth of muscle memory I'm fighting against too (particularly w/ x)

Edit: I'm not asking you to add this feature necessarily; just noting the behavior that I expected. I don't know if I know enough to submit a PR w/ an example of the behavior I expected, but I can certainly give it a shot.

[ggandor]

I removed the x/X mapping from Visual mode, the gain is too little compared to the potential public outcry, and I also like the symmetry of the current scheme.

What I'd really like is to do something like this:

We cannot put an option into setup if we want zero-config (i.e. no need to call setup) though, even if it's only a "disable" switch. I don't want it to be too visible in the first place, but the more compelling reason is that that would be misleading, as the honest name should be something like remove_keymaps_that_are_already_set (and that sounds ridiculous :) ). Theoretically the following situation could arise:

1. source lightspeed.nvim 
    keymaps are added (because of zero-config auto-setup)
2. source foo.nvim 
    foo.nvim, a similar plugin, might be prevented to add its own keymaps, because
    it sees that Lightspeed has already occupied them
3. Lightspeed setup is called with the "disable mappings" flag
    the user might falsely assume that there are no side effects to worry about

The best compromise is to expose a function that could be used like:

require'lightspeed'.remove_keymaps()

I could do that obviously, but I still think that's unnecessary, ugly over-engineering for a minority use case, when all one has to do is etiher unmap s | unmap S or unmap f | unmap F | unmap t | unmap T. (Both at the same time just doesn't make sense, that means you don't need this plugin.)

[jaydorsey]

We cannot put an option into setup if we want zero-config

I don't understand this so maybe I wasn't clear; you have configuration options (in the README). This would just be another. Users who don't do custom setup would get the default behavior of loading all the custom keymaps.

Per your README example (truncated, below, with what I think the OP is asking for), it would just be adding an additional configuration here which would skip calling the default

require'lightspeed'.setup {
  -- You must define your own mappings
  disable_default_mappings = true,
  ... removed ...
}

-- define key mappings
vim.api.nvim_set_keymap('n', 'f', '<Plug>Lightspeed_f', {silent = true})

the user might falsely assume that there are no side effects to worry about

Easymotion for example, provides a way to disable the default mappings with EasyMotion_do_mapping flag.

the gain is too little compared to the potential public outcry, and I also like the symmetry of the current scheme.

If you prefer people "opt out of the keybindings they don't want", versus "opt in to the ones they do want" I can respect that as your design decision. You've given more than enough examples of other ways that the user can override the automatically created maps

[ggandor]

We cannot put an option into setup if we want zero-config

I meant that technically we can do that of course, but explained below why I think that would leave some room for confusion, and could cause problems for inexperienced users in some situations (or would require too many comments/sidenotes). (It might still cause conflicts with other plugins, even if one calls the setup with the disable flag, because all we can do now - if not making setup mandatory - is to remove the automatically added mappings after the plugin has been sourced.)

I'm not excluding the possibility that at some point I'll just introduce a breaking change, and require users to call setup if they need the default mappings (now it's not obligatory); then there would be a true opt-in flag, like set_default_keymaps, that is set to true by default. Maybe that would be the simplest thing to do.

[mikeri]

First of all, Lightspeed is awesome! A brilliant idea elegantly implemented. Thank you, @ggandor, and much respect!

However, and I'm sorry for posting a "me too" comment, but I really think it should be emphasized how overriding ftFT breaks macros, something that also lead me to this issue. The idea that breaking commonly used functionality should be avoided is a common thought among most plugin developers as far as I've seen. I do not buy the arguments used about "inexperienced" users needing zero-config, as we are talking about about a plugin/script for a fork of an already highly technical tool with a steep learning curve. Really, what inexperienced users are using neovim?

I suggest that at least note about the macro breaking and how to properly disable the default override should be easily discoverable, preferable in the readme. That way at least users will not be surprised or confused when their workflow breaks.

[ggandor]

@mikeri

First of all, Lightspeed is awesome! A brilliant idea elegantly implemented. Thank you, @ggandor, and much respect!

Thanks so much, this is always good to hear. <3

I do not buy the arguments used about "inexperienced" users needing zero-config, as we are talking about about a plugin/script for a fork of an already highly technical tool with a steep learning curve. Really, what inexperienced users are using neovim?

I don't necessarily agree, but we don't have hard data. In any case it's indicative that batteries-included bundles like LunarVim has 5k+ stars already, the demand is there. Everyone was a newbie at some point in Vim/Neovim.

at least note about the macro breaking

https://github.com/ggandor/lightspeed.nvim/tree/0bc3acda929b946e175d83a5f702d28d231b0089#notes

how to properly disable the default override should be easily discoverable, preferable in the readme

https://github.com/ggandor/lightspeed.nvim/tree/0bc3acda929b946e175d83a5f702d28d231b0089#keymaps

(Obviously I won't open the readme like "Hey, this is my cool plugin. It breaks your macros, you can disable suff here... Other cool features: (...)", so I really don't know what more should I do :D) Edit: Okay, maybe it would indeed be good to mention it somewhere at the beginning, until we solve the corresponding issue.

[mikeri]

at least note about the macro breaking

https://github.com/ggandor/lightspeed.nvim/tree/0bc3acda929b946e175d83a5f702d28d231b0089#notes

how to properly disable the default override should be easily discoverable, preferable in the readme

https://github.com/ggandor/lightspeed.nvim/tree/0bc3acda929b946e175d83a5f702d28d231b0089#keymaps

I stand corrected, I obviously did not do my due diligence on this one. (But I am pretty sure I did read trough the readme sometime in the past.)

(Obviously I won't open the readme like "Hey, this is my cool plugin. It breaks your macros, you can disable suff here... Other cool features: (...)", so I really don't know what more should I do :D) Edit: Okay, maybe it would indeed be good to mention it somewhere at the beginning, until we solve the corresponding issue.

An alternative could be something after the introduction like "This plugin has an all inclusive, zero config approach to be beginner friendly. The following snippet will disable all default mappings", letting the users paste the snippet into the config and remove the lines for the mappings they want to keep.

[Dema]

Can you add a section in README on how to use your plugin with vim-sandwich by inexperienced user? I'm currently stuck, I don't have a lot of experience with vim and I have no idea how configure both plugins to work together.

I think making it one-liner to please absolute beginners but making it very hard for the same beginners to use both plugins is kind of failure to achieve user friendliness :smile_cat:

I'm okay with copy-pasting several lines of code instead of one, I'd love to have some examples in README on how to integrate your plugin with others that have some conflicting mappings and stuff. Like "If you use vim-sandwitch, paste this code"

[ggandor]

@Dema Could you open a Q&A question in the Discussions instead? (Just copy your above comment there if you want.) I'll answer there, so that it's more easily discoverable by others (and the question is not about "reverting to the native settings" anyway, but resolving conflicting defaults between two plugins). Thanks!

[bdillahu]

Just to add to the count - I also fall in the "please have a way to disable key bindings" - I don't wish to replace the default vim functions (in any mode), but I do wish to be able to use lightspeed... for me, I would map things to "s" for your "s", etc. The extra keystroke is worth it to me.

I understand that's not true for everybody, but just wanted to put it out there. Thanks for your work on this!

[ggandor]

@bdillahu I'm not sure we're on the same page, what's the problem with defining custom keymaps? like

nmap <Plug>Lightspeed_s <something>
nmap <Plug>Lightspeed_S <something>
etc.

Lightspeed will not override the default s/S in that case, if you do that before sourcing the plugin. Or you can unmap s | unmap S after loading the plugin, and then defining custom keymaps (that makes less sense of course, but the result is equivalent), and there you have your native s/S again.

for me, I would map things to "s" for your "s", etc. The extra keystroke is worth it to me.

Sorry, I don't understand what you're trying to achieve ("s for your s", "extra keystroke"), please elaborate.

[bdillahu]

@bdillahu I'm not sure we're on the same page, what's the problem with defining custom keymaps? like

nmap <Plug>Lightspeed_s <something>
nmap <Plug>Lightspeed_S <something>
etc.

Lightspeed will not override the default s/S in that case, if you do that before sourcing the plugin. Or you can unmap s | unmap S after loading the plugin, and then defining custom keymaps (that makes less sense of course, but the result is equivalent), and there you have your native s/S again.

I did the unmap method and that does work… I was just putting in my “vote” for their to be a more straightforward way. This works, and beggars can’t be choosers, and it’s your product :-)

for me, I would map things to "s" for your "s", etc. The extra keystroke is worth it to me.

Sorry, I don't understand what you're trying to achieve ("s for your s", "extra keystroke"), please elaborate.

Sorry, I typo’ed that… I’m mapping s to be equivalent to what by default is just “s” - I just don’t want to override core vim key shortcuts (at least ones that I have built into my brain at this point).

Thanks again…

[Dema]

For anyone who wants to set up lightspeed in "recommended" configuration with vim-sandwitch using vim-surround bindings in lua config

  use { "ggandor/lightspeed.nvim" }
  use {
    "machakann/vim-sandwich",
    config = function()
      vim.cmd [[runtime macros/sandwich/keymap/surround.vim]]
    end,
  }

[osleg]

https://github.com/ggandor/lightspeed.nvim/pull/111 Forked and updated to allow preventing the mappings without workarounds and weird hacks. I'm not going to keep my branch in sync with master so if anyone is interested in using it you better get a patch (unless it get merged in to master here of course)

@ggandor I'd like to say that I love your plugin but your stance on the settings, and most important on default mappings is in my personal opinion is sub optimal. There are people who use vim for decades and taking over our mappings is bad idea. Even worse idea is not allowing to disable default mappings for you plugin without workaround which might (and does) break other plugins.

[ggandor]

See #111. I just like to note here that in case unmap is problematic for you for whatever reason, and you have an inexplicable aversion to using placeholder mappings before sourcing, then, instead of the above linked PR, it's much simpler to comment out the line: https://github.com/ggandor/lightspeed.nvim/blob/9fddb6ebf4007eaa26f44cd31b5140cbd3bbb820/lua/lightspeed.lua#L2215

[ggandor]

workaround which might (and does) break other plugins

How could either unmap or a placeholder mapping break any plugins? unmap means you need the default Vim behaviour anyway. A placeholder mapping before sourcing is, by definition, should use some key that is not in use.

[D00mch]

I want to remap s to q, and q to space-q.

.vimrc: map <space>q q

init.lua: vim.api.nvim_set_keymap('n', 'q', '<Plug>Lightspeed_s', {})

q doesn't work. Space-q behaves like Lightspeed_s.

————————————— By the way, I like the approach conjure plugin has. You don't have to think about remapping and unmapping anyting, just set keys you prefer:

:let g:conjure#mapping#prefix = ",c"
:let g:conjure#mapping#log_split = ["ClS"]

[ggandor]

@Liverm0r You need to use noremap: noremap <space>q q. map works recursively, that is, if there are already remapped keys on the right hand side, then it will use those as such - as if you've written <space><Plug>Lightspeed_s. nvim_set_keymap, however, works non-recursively by default, and it can be made recursive by {remap = true}.

[lateef-k]

I want to remap s to q, and q to space-q.

.vimrc: map <space>q q

init.lua: vim.api.nvim_set_keymap('n', 'q', '<Plug>Lightspeed_s', {})

q doesn't work. Space-q behaves like Lightspeed_s.

————————————— By the way, I like the approach conjure plugin has. You don't have to think about remapping and unmapping anyting, just set keys you prefer:

:let g:conjure#mapping#prefix = ",c"
:let g:conjure#mapping#log_split = ["ClS"]

It's funny, I had the exact same thought. I use the S key extensively just out muscle memory, so I wanted to map the plugin to q/Q since I use macros infrequently enough that I'm willing to add an additional keystroke for it.