This is all really inside out. It would be much better to store the help
in a single file and use asciidoc/docbook's capabilities to split it if
desired.
If <label> elements are found use them, else use the value in the box
(current behaviour) or if you add 'name' to 'hintinputs' then it will
allow you to select by the name of the field.
For values that are not displayed on the input field, it adds the value
to the red hint icon.
Mostly typos/omissions/markup errors, more remarkable e. g. changing
'b' to 'B' in tutorial reflecting a change from 1.2.
Also uncommented [macros] section in asciidoc.conf (is that right?).
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
At the moment, only "syntax=asciidoc" was specified. The
asciidoc_filetype.vim that is distributed with Asciidoc gives the
installer two options -- to either associate every *.txt file with
asciidoc or to try to decipher whether or not the file is an asciidoc
using the first 50 lines.
So it's not given that a developer will open the *.txt files with
ft=asciidoc, and so it's helpful to have it explicitly in the modeline.
Again, by Chicago Manual of Style (CMOS) and several other style guides, we
hyphenate compound /modifiers/ when they come /before/ the word being
modified.
So the "command line" is not hyphenated, but the "command-line mode" is.
This is consistent with Vim help style conventions as well.
Most of the special case asciidoc replacements were also removed since
they're a bit confusing and doing so results in a 60% improvement in the
time taken by asciidoc to process the help pages. Unfortunately, I'm
now limited to preparing a three course menu for my guests while it runs
rather than the degustation extravaganzas of the past but such is life.
It's still a bit of a mess but since we're almost certainly moving to
something else in the near future it's probably not worth cleaning it up
before 2.0 is released.
