bring back leader key

[ilan-schemoul]

Issues

• I have checked existing issues and there are no existing ones with the same request.

Feature description

neorg_leader was just fine. I'm very surprised that you use , it feels old-school and doesn't work well with lazy. I want to have "g" only for neorg (as I had before) but lazy cannot do it

  vim.api.nvim_create_autocmd('FileType', {
     pattern = 'norg',
     callback = function (_)
       vim.g.maplocalleader = "g"
     end,
   })

Lazy will give error " You need to set vim.g.maplocalleader BEFORE loading lazy"
Can we bring back neorg_leader

It's a good project and I don't like to criticize open source project but a ton of things keep breaking without the breakage adding any functional feature. I strongly dislike the many number of breaking changes this package do. In most cases it feels like goin backward: multiple changes do installation process with lazy, remap_event removed to bring back vim style <Plug> (when nvim plugins typically use something like vim.keymap.set('a', require('norg').create_line()), "neorg_leader" removed to use old vim style . Please slow down the backward incompatible changes, especially when they don't add anything functionally (think about the thoushand of devs wasting hours because of breakage which don't add anything)
If it's ain't broken don't fix it :)

Help

Yes

Implementation help

No response

[max397574]

1. that maplocalleader should be oldschool is just completely wrong. It's whole purpose it to be used in a scenario like this where you have mapping only for specific buffers (in this case norg ones).
2. The installation prozess had a breaking change because lazy.nvim has now a builting mechanism for this which is much better to use
3. The mapping system was reworked because it was a pain to work with it, e.g. not being able to unmap keys properly and adding new ones was horrible ux
4. mappings aren't "old vim style" They are a builtin functionality of neovim just as well (upstream to :help lua-guide nvim-neorocks/nvim-best-practices#5 (comment))

so things were broken and are much better now
in addition to that these breaking changes were really well documented and quite easily fixable

even if lazy wouldn't complain about you setting maplocalleader somewhen after loading it it still wouldn't work
because if you create mappings with leader or localleader the value of it at the time the mappings are created is used
that's the exact reason why you should set it early

it's unfortunate that it isn't easily possible to change the prefix easily only for neorg and have it different from maplocalleader
but not using localleader and reintroducing something to overwrite it would be a step backwards imo

[ilan-schemoul]

It's whole purpose it to be used in a scenario like this where you have mapping only for specific buffers

it's unfortunate that it isn't easily possible to change the prefix easily only for neorg and have it different from maplocalleader

Doesn't those two things contradict themselves ? That's the whole problem for me. Local leader, should by definition be local, but if I can't modify it after lazy is loaded then I can't modify it and made it local ? I'm missing something here.

mappings aren't "old vim style" They are a builtin functionality of neovim just as well (upstream to :help lua-guide nvim-neorocks/nvim-best-practices#5 (comment))

Mappings aren't old school. I've used hundreds of plugins of both vim and nvim over 6/7 years very extensively and, yes, <Plug> is uncommon in nvim community. Following what's commonly used elsewhere is not a bad idea.

Moreover my main point stands, I've never seen in my life any package introducing so regularly breakage not adding anything functionnaly. It's really annoying. Everytime I update all my packages then I spent a bit of time fixing neorg then I think it's good and then regularly discover new problems. I use neorg extensively for my job, my livelihood, I'd appreciate me not wasting hours for no good.

I've followed and contributed to open source project for more many years and I've never seen that.

It's important to focus on the end user and try not to break everything needlessly all the time. When hours of thousands of software engineers are wasted it's the equivalent of 10s/100s of thousands of dollars wasted (if we take the salary of an average dev in the west)

The mapping system was reworked because it was a pain to work with it, e.g. not being able to unmap keys properly and adding new ones was horrible ux

I can agree it was bad now it's ok. But we can make it backward compatible. But at least I can understand that so I won't complain about it.

[benlubas]

Local leader, should by definition be local, but if I can't modify it after lazy is loaded then I can't modify it and made it local

The purpose of local leader is to be the leader key for buffer local mappings. It's not supposed to change for different buffers (this would make it's usage very confusing, mentally strenuous, and inconsistent).

I've never seen in my life any package introducing so regularly breakage not adding anything functionnaly

We use semver for a good reason. Not b/c we like watching numbers go up. If you don't have time for updating, I totally understand. You can (and sounds like should) pin the version of this plugin to the latest major version and only update when you have extra time or see a feature that you really want. If the plugin breaks on you, that's on you, you're in total control of when our breaking changes impact your usage.

I'll add that a lot has improved over the past two major versions despite things moving slower than we'd like at the moment (people are just working on related projects instead of the core neovim plugin right now, and on top of that life is getting busy for a lot of people at the same time).

Features are still being added (take a look at my PR history), link autocomplete is just one of quite a few new features.

[benlubas]

and I'll close with that b/c this discussion is not gonna be productive. You can create your own keybinds if you want them to start with g