Align behaviour of maps, cmap, nmap, vmap and cmd to Vim

[CatsDeservePets]

In Vim, when running map (and the others*) without any arguments, it shows a list of all the binds.
In lf, it incorrectly gets interpreted as the key \n which then lf tries to unmap.

This PR fixes the incorrect interpretation and also calls the associated command to list the binds (i.e. maps, vmaps, ...) when run without any arguments.

*cmd doesn't exist in Vim

[CatsDeservePets]

Any thoughts on this, @joelim-work?

I never understood why there are separate commands instead of using the existing ones.
The only benefit I see is being able to easily remap them.

[joelim-work]

I think the reason was simplicity, the fact that map has its own command object (mapExpr) means that it was only ever intended to create mappings. In other words, each command does one thing and one thing only - by combining map and maps together under a single command, you achieve the goal of replicating Vim behavior, at the cost of some additional complexity.

So the question is what should map without any arguments do? It could be either to display keybindings, or result in an error. This sounds rather opinionated to me, but I would say that if you want to have map display the keybindings, then maps shouldn't exist anymore - I don't think it's a good idea to have two similar sounding commands do the exact same thing.

[CatsDeservePets]

I think the reason was simplicity, the fact that map has its own command object (mapExpr) means that it was only ever intended to create mappings. In other words, each command does one thing and one thing only - by combining map and maps together under a single command, you achieve the goal of replicating Vim behavior, at the cost of some additional complexity.

I do recognise this.

So the question is what should map without any arguments do? It could be either to display keybindings, or result in an error. This sounds rather opinionated to me, but I would say that if you want to have map display the keybindings, then maps shouldn't exist anymore - I don't think it's a good idea to have two similar sounding commands do the exact same thing.

Just because I am collaborator now, I don't want to shape lf to fit my vision only.
But at least for me, it's always a bit of mental friction to type the right command, whether I am inside Vim or lf.

I don't like having 2 ways of doing the same thing either but I also don't want to introduce breaking changes again.

If we removed these

cmd maps $lf -remote "query $id maps" | $PAGER
cmd nmaps $lf -remote "query $id nmaps" | $PAGER
cmd vmaps $lf -remote "query $id vmaps" | $PAGER
cmd cmaps $lf -remote "query $id cmaps" | $PAGER
cmd cmds $lf -remote "query $id cmds" | $PAGER

should these states even be queryable anymore? How would a PowerShell user get this working? That is the main intent why I did not remove the original queries in this draft.

Maybe it's better to leave it as it is.

---

Sadly, I don't see a way of overwriting built-in commands that still call the original one internally without having to type a different function name. If this was possible, I could just write my own command.

[joelim-work]

I thought about the problem a bit more - the difference between Vim and lf is that with Vim, displaying mappings is fully built-in and not customizable. With lf, maps is technically a user-defined command that just happens to have a default provided (depending on the OS), and actually has to be redefined if using a different shell like PowerShell.

So now you have the situation where you are trying to extend a fixed built-in command (map) to include custom behavior. It is not possible to redefine built-in commands like map so your solution is to forward it to a different command instead which can be redefined, but this creates duplicate commands (and introduces coupling into the code).

I wonder if there is an alternate solution for this. You could define a keybinding for maps if you use it frequently enough. Or you could try defining cmap <enter> ... instead, and check the contents of the command line, but it requires support added to export it first.

[CatsDeservePets]

Another, different idea I got which is rather off-topic: Create a new hook command on-cmdline-exec or something like that. It gets fired when pressing <enter> and receives the current cmd-line. It transforms the strings and executes them instead. This is a specific use case but I think this could solve more things, e.g. aliasing z with cd without writing something else.

[joelim-work]

Such a hook command can only be used when entering a command to be executed. I guess it's possible a user might want to manipulate the command line while editing a command though, but it is also quite a niche use case. I think either of these solutions is more flexible and preferable than the current PR. The only downside is that it is not default behavior, but at this point I doubt there is a perfect solution that avoids making some kind of tradeoff.