See http://vimperator.org/trac/ticket/126
Using...
function (args)
{
let args = args.string;
...
was causing Firefox to complain that args was undefined. Changing the
"let" to "var" or changing the names of the variables (e.g., changing
"function (args)" to "function (arg)") fixes the problem. IMO, this
appears to be a bug in Firefox.
The short fix would be to change the formal argument from "args" to
"arg." However, that would make delmarks' implementation different from
all the rest. So changed "let args" to "let argstring" and adjusted
throughout the function.
* The stdin - wasn't needed. However, an ||true is now used to prevent
Makefile from erroring out (I'm sure there's a better way).
* muttatorrc was spelled muttatororrc; fixed now.
* The vimperator.vba was not included although muttator.vba was.
* Adjusted Makefiles so that vim is called with "-" to open stdin (that
was required on my Vim7.2 system; does it break others?)
Files like vimperator.vim, javascript.vim, and vimperatorrc.example
might fit better in a "contrib" directory. It's not clear whether there
should be vimperator/contrib and muttator/contrib directories or a
single liberator/contrib directory.
The Makefile.common doesn't include these files in the bundle, and so it
doesn't seem like a bad idea to package them in a single
liberator/contrib directory with a CONTENTS or README file giving a ToC
for the directory.
* Require language part of locale to be two lowercase letters.
* Update Makefile.doc comment -- add "include" comment.
* Get rid of muttator/locale/en-US/Makefile symlink in favor of include.
This commit is in the spirit of
a3fc60c011b8ed42c2efec2147b1268abc10d578.
Vim's help format really numbers everything manually? Sections too?
That's unbelievable.
Also added rough documentation for insert mode.
TODO: Abbreviations should also expand on <CR> and <Tab>, but right now
adding <CR> to the mappings.add() has no effect, and adding <Tab> to the
mappings.add() breaks tab completion.
TODO: Rather than listing non-keyword characters in two places (ui.js
and mappings.js), they should be specified in one location (that could
someday be trumped by an 'iskeyword' option).
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").
Until liberator.NEW_BACKGROUND_TAB operates differently based on the
setting of browser.tabs.loadInBackground, this code must remain. At
the moment, NEW_BACKGROUND_TAB only opens a true background tab if
loadInBackground=true. When loadInBackground=false, the meaning of
NEW_TAB and NEW_BACKGROUND_TAB flip. Hence, until they're invariant,
something like ;F (which must always load tabs in the background)
has to pay attention to loadInBackground.
Before, only a opened in the new window. b and c opened in background
tabs.
Please review this patch. Feel free to refactor or revert. I'm not
entirely comfortable with the solution, but it was small.
Bug reported in http://vimperator.org/trac/ticket/119
The implementation provides the same functionality as ;F while still
maintaining the Vimp2.0 style hints. There is definitely room for
refactoring here.
Ted Pavlic