At this point, I'm thinking about supporting continuity and adoption. Some users will want to change and some will want to stay the same.
The short answer is not to define any abstract commands or forbidden / reserved sequences if you want the current behavior. We can start by only defaulting abstract commands that are effectively in consensus already.
After adding the obvious abstract commands, there's not many bindings that map to consistent concepts I can think of. However, this is not the problem it seems like. While a major mode author may wish to create more bindings, they are not entitled to any of the user's keyspace.
It will suffice for mode writers to know which key sequences are:
At the time of map generation, if a mode finishes mapping designated abstract keys, they must choose keys that don't match the other two groups. These bindings may all be suboptimal or too few to implement the mode writer's wishes, but this is the user's choice. A user-overridable sequence successor function could add bindings to a set of valid sequences. If a mode needs more than just a single prefix key, this should suffice, and the user can define that function to nil to block all extraneous bindings.
Mode authors should focus on introducing their commands through README's, good docstrings for completions, and good command names. Bindings are not a good index of discovery for commands. If a mode has a well implemented data model and set of functions for building commands, this is much more useful than having a bunch of maybe useful commands bound.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4