vimdoc
vimdoc copied to clipboard
google
Helpfile generation for vim
When I put `@function(maktaba#error#Shout)` in library.vim, vimdoc dies because it can't find maktaba#error#Shout. Note that there's likely some randomness involved here depending upon which plugin file is loaded when. Vimdoc...
If vimdoc directives are above the first `@usage` line in a doc comment block with multiple `@usage`s, they only apply to the first `@usage`. For instance, given: ``` VimL ""...
This is a little nicer than just tossing "[foo] is value by default" at the end of the doc paragraphs.
The various types of list (see output.py HelpFile.WriteParagraph) are poorly documented and stringly typed. We should explicitly differentiate between the different types of lists in the parser.
The documentation says vimdoc supports multiple `@usage` directives on the same command or function. This does work for very simple cases, but has quite a few bugs. Attempting to link...
Vimdoc supports auto-generated tags for most documentation items (sections, functions, commands, etc.), but doesn't have a way to render arbitrary tags. For instance, something like this would be useful for...
There should be a way to document individual mappings so they're listed in the mappings section of help files. We should probably just have an explicit `@mapping KEYS [mode]` rather...
Vimdoc is designed to separate the parser from the outputter. It shouldn't be too difficult to write an html output mode.
It's easy to get confused and write `@function(name())` in vimdoc since the doc tag includes parentheses (`name()` vs `name`). We should consider accepting `@function(name())` as equivalent to `@function(name)`. Note this...
For example, `@function(Whatever)` should validate that the 'whatever' function exists. (This gets a little tricky if people reference builitn functions or functions from other plugins.)