This reverts commit a401e3ebf34c964ca508c189e1daf9b0b18e57b9.
Explicit numbering is easier to read, and will likely be required if and when
we switch to Vim's help format.
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.
This reverts commit 1455b9d27224b1289e7762fef3c4d158c7074877.
"Command line" should only be hyphenated when it is a /leading/ compound
/modifier/. For example, "command-line interface." See CMOS (or
Strunk/White) for more information.
Automatic numbering exists for a reason. It's more elegant and easy to
manage. Additionally, because numbering rules can be specified centrally,
it adds consistency to the final look of the documents. An editor shouldn't
have to think about the current numbering level or number. That should be
handled by asciidoc as it builds the final doc.
[ However, added explicit first number to make list source code look a
little better. ]
Also moved $VIMPERATOR_INIT keyword to its correct location in
starting.txt.
This change partially reverts changeset a1f264639f27d7d5b87e5fbccf54d6890a03ca7d.
For now, the internal equivalent of "iskeyword" is [^\s'"].
In the future, the internal "iskeyword" equivalent can be expanded. It may
be overboard to add an "iskeyword" option, as it applies to lots more
things than :abbr. Additionally, it's not clear why it's bad to call
keyword characters everything except whitespace and quotes.
TODO: Should abbreviations be triggered by any non-keyword character?
TODO: Should abbreviations be triggered by <CR>?
TODO: Should abbreviations be able to include <Left>, etc.?
"this.contexts = { "/": this }" in CompletionContext(...)
was causing ":set defsearch=google<cr>" (and similar) to error
with infinite recursion. Restoring to
"this.contexts = { name: this }" fixes the problem, but does it
break other things?
Please review.
a.) Cleaned up copyright language to match conventions.
(I used the memoir document class documentation as a reference, but
these conventions are common throughout publishing)
* The (c) symbol has no legal meaning. Only the word "Copyright" and
an encircled lowercase c are appropriate. So the word "Copyright"
was placed before each (c).
* Each (C) was changed to (c).
* Kris uses the correct symbols in copyright notices, but those
symbols can be problematic in terminal-mode editors. Added the word
"Copyright" as well.
* Replaced colons/spaces after years with the word "by."
b.) Added a copyright notice to common/content/template.js. It was
missing one entirely. Please correct if it doesn't need one or if the
copyright isn't held by Martin.
c.) Also added a "tildetidy" target to Makefile common that includes a
version of the find line from the existing "clean" target (however,
this version uses "rm -fv" instead of "rm -f").
