Auto documentation based on setting, command and key binding reflection/introspection

David K. Hess 10 years ago updated by glyph 9 years ago 4
If you add the ability to introspect all of the built-in commands, loaded commands, settings and key bindings, then we could write a plugin that would go through all of that and generate an HTML documentation page that could be opened in an external web browser.

Good and accurate documentation for not a lot of work.
Yes! Please add an api to do this. I was bitten recently by a plugin disabling standard functionality by overriding a mouse mapping.

With an api to introspect all mappings, we could for instance create conflict reports that shows when the same binding has been used for different commands.
Absolutely.  I've been able to get Sublime's keyboard input to react exactly as my fingers expect (given 15 years of using Emacs heavily), but C-h k ("tell me what this key binding does") and C-h w ("given the following command, tell me where it is bound to a key") are impossible to replicate with Sublime's current API, as far as I can tell.  It would be great to remove that limitation.

(Although I should note that sublime.log_commands(True) comes very close to the former.)

As another user migrating from emacs, this is something I miss a lot, particularly when trying to develop plugins.

I chose sublime text over competitors because of its apparent philosophy of simultaneous simplicity and flexibility. Auto-documentation in this style is clearly fits that approach: it helps solves the documentation problem in a straightforward way and it provides various ways for the user to get that information — statically via generated markup or interactively in the editor.

Please consider this, it would be a huge help, especially to plugin developers. And not only would it help to document the editor, it would also encourage plugin developers to document their code better as well.

As long as we're talking about plugin development - it would also be really handy for the describe-key [i.e. C-h k] equivalent to also display some information about why a key was mapped.  In a few cases I've been confused as to why Sublime chooses one key over another when both of their context conditions are all true, or what plugin has decided to map a particular command.