Problems with the original:
- Addressing the column with "l" assumes that "G" positions the cursor on the first column. But the default behavior already skips leading indent (so is wrong when there's leading whitespace), and with ":set nostartofline", the current column actually is kept (which completely and randomly messes up the column addressing).
- ":normal" without ! is affected by mappings; users may have tweaked the "G" and "l" (or in the worst case completely changed the behavior, e.g. for use with a different keyboard layout).
This change makes the mapping immune to mappings (with ":normal!") and uses the "|" command (which uses virtual column addressing independent of the current column or "G" behavior) instead of "c".
Additionally, "zv" makes the current line visible should it be obscured by folding. (Vim may detect a filetype and automatically enable folding.)
Instead of -c <cmd>, the shorter +<cmd> form is used. This is just a cosmetic change. Using just a single argument and avoiding any whitespace within it may prevent command-line argument parsing issues.
It's important to have async functions return promises as this ensures
that composite commands run in a deterministic and unsurprising order.
Also, making `:sanitize` synchronous might fix all issues we have with
Tridactyl not sourcing tridactylrcs entirely.
Add a flag `-s` to source js files from user's config directory:
:js -s test.js
With the ability to load js files, `tridactylrc` can have its javascript
code into seperate files.
Since the js code was run by calling `eval()` in local score of calling
function, the variables and functions decleared in the js file will lost
after eval().
To make the content of javascript file reusable, user could export
functions into some globals like `window.` or `tri.`.
It was reading properties that a scroll event does not have.
It was messaging the background page with an expensive call on every
scroll event. This slowed down the page unnecessarily.
Also extracted jumps.timeoutid to the content script scope.
This variable is not useful to others outside of the current content
script. Storing it locally means we can avoid expensive communication
with the background page and only do it once we're sure we need to add
a new entry to the jump list.