chore: update typescript from 3.8.3 to 3.9.2

Done using:

    yarn add typescript --latest --exact

style: format source

refactor(tampermonkey): mitigate concerns with GitHub security

This is funny. macOS has a built-in Apache webserver, so we can
configure it file up our user scripts locally, mitigating concerns with
GitHub security mentioned in e8f40653, and giving us file-system access
without actually elevating extension privileges, so we can add one more
row (level 5) to our risk-impact matrix:

    | Level | Description    | Risk   | Impact |
    | ----- | -------------- | ------ |
    | 0     | Don't use      | None   | None   |
    | 1     | Copy-paste     | Low    | Medium |
    | 2     | Full FS access | Low    | High   |
    | 3     | Remote URL     | Low    | Medium |
    | 4     | Browser sync   | Low    | Medium |
    | 5     | Local URL      | Low    | Medium |

Effectively, we have the power/flexibility/immediacy of level 2 now,
while maintaining the risk that we used to have at level 1.

fix(tampermonkey): add ".user" pre-extension

Not sure if it matters, but I can't get Tampermonkey to "see" updates to
these scripts, and this might help.

fix(tampermonkey): provide downloadURL as well

Not sure if GitHub is caching aggressively, but Tampermonkey doesn't
seem to be picking up updates.

feat(tampermonkey): add updateURLs to scripts

Despite the misgivings expressed in e8f40653, going to give this a try.
If it works out ok and I feel comfortable with it, may end up deleting
or modifying the tasks in this aspect, as I have pretty much ruled out
granting filesystem access at this point.

chore(vim): update Command-T submodule

* aspects/vim/files/.vim/pack/bundle/opt/command-t d044bac...9c7f812 (1):
  > chore: battle bit-rot in gem dependency graph

feat(portool): add shortcut for running ci:bundle bundles

Unpack the bundle and in the unpacked directory run `portool run
bundle`.

Assumes you have a DB created with:

    CREATE DATABASE `lportal_bundle` DEFAULT CHARACTER SET utf8;

Ghastly hacky. Will eventually clean all this up one day.

chore(tampermonkey): update script headers

Preparing to potentially move these somewhere I can have them
auto-update. I probably won't though, because I don't really like the
security implications:

0.  Don't use Tampermonkey

    This is the baseline, with no additional risks.

1.  Install via copy-paste (ie. current set-up)

    You have to trust the extension itself not to do anything malicious.
    It has access to every page you visit, and can run arbitrary code.
    Millions use it, but ultimately unless you're auditing the source
    every time you install and update it, you are trusting the developer
    to be competent and non-evil.

2.  Grant access to local file system and pull in script using
    `@require`.

    Same security profile as above, but you're additionally now trusting
    the developer not to do anything malicious involving accessing
    arbitrary files on your filesystem. If you trust the developer not
    at level 1, you can probably trust them at level 2, but there are no
    guarantees at either level, and there is a reason why browsers try
    to sandbox access to the local filesystem.

3.  Update script from GitHub (or similar) URL.

    Instead of worrying about the filesystem, you now have to worry
    about the integrity of GitHub's web servers and Git storage. If
    somebody can push to your repo, or otherwise fake a response from
    you, they can arbitrarily substitute their own malicious userscript
    for your own.

4.  Via Browser Sync.

    From:

    https://www.tampermonkey.net/faq.php#Q105

    > Please note that you have to be signed in to your browser and that
    > the amount of data that can be synced is very limited. That's
    > why Tampermonkey needs a publicly accessible URL to sync your
    > scripts. To be clear on that: only scripts that are downloaded
    > from a web server or that contain a valid @downloadURL tag are
    > processed.

    So, basically same threat model as level 3, as far as I can tell.

Summarizing relative risk/impact:

    | Level | Risk   | Impact |
    | ----- | ------ | ------ |
    | 0     | None   | None   |
    | 1     | Low    | Medium |
    | 2     | Low    | High   |
    | 3     | Low    | Medium |
    | 4     | Low    | Medium |

Overall, I think I'm going to sit on it for a bit before making a final
decision, but based on the table above we can probably rule out level 2
already.

chore(portool): update my fork with contents of brianchandotcom/master

In local builds, continue to build off of upstream/master (which should
be somewhat more stable), but in terms of updating my remote fork,
always track the latest: this makes it more likely that people sending
me pulls against my master won't end up dragging in a bunch of commits
from brianchandotcom/master (if they've based their work off that),
which makes PRs hard to review.

Downside is that they might see conflicts they wouldn't otherwise see
basing their work off upstream; but those conflicts are conflicts they
would eventually see anyway, so I think this is ok.

refactor: prepare to add "Tampermonkey" aspect

In service of: https://github.com/wincent/wincent/issues/83

feat(vim): run update-help-tags every time

refactor(vim): split update-help-tags off from update-bundle

fix(vim): allow Command-T to open items in Dirvish windows

I had this old hack in there for the sake of netrw; just need to update
it for Dirvish.

chore(vim): update Command-T submodule

* aspects/vim/files/.vim/pack/bundle/opt/command-t 1d67adc...d044bac (1):
  > Merge branch 'pull/369'

docs: fix typo in comment in README

refactor(corpus): scope command-line mappings more tightly

Although, as noted in the comments, could do this a little more
conservatively. I think I'll just provide settings to override the
mappings so that you suppress them if you want.

chore(vim): update Pinnacle submodule

* aspects/vim/files/.vim/pack/bundle/opt/pinnacle 2f2ff8e...ae6b03a (1):
  > fix: don't use trim() without checking first to see if it exists

chore(vim): update Ferret submodule

* aspects/vim/files/.vim/pack/bundle/opt/ferret 24633d3...ea59ba1 (3):
  > docs: try to make the quoting examples even clearer
  > docs: try to make quoting examples easier to read
  > Merge branch 'pull/71'

fix(git-hub): guard against potential "current_branch" problems

Just checking other places where "current_branch" might cause us trouble
on a detached HEAD.

feat(git-hub): improve handling of detached head edge case

This improves on the fix in the last commit.

Instead of bailing if `git rev-parse --abbrev-ref HEAD` returns "HEAD"
and just skipping the `git branch --set-upstream-to` call, try to figure
out the branch by parsing the output of `git branch --contains HEAD`. It
will pick the first name that it finds matching the pattern
"refs/heads/something". That means, in a typical detached head situation
where `git branch --contains HEAD` would print:

    * (HEAD detached at 24633d3)
      master
      some-other-branch

it would pick "master".

Example output of a run (eg. `git hub get 71`):

    Branch 'pull/71' set up to track local branch 'master' by rebasing.
    Previous HEAD position was 24633d3 feat: make tab completion append trailing slashes to directories
    Switched to branch 'pull/71'
    Your branch is ahead of 'master' by 1 commit.
      (use "git push" to publish your local commits)

fix(git-hub): don't let `git hub get` explode if on detached head

Can happen in submodules pretty easily. Avoids problems like:

    fatal: Cannot setup tracking information; starting point 'HEAD' is not a branch.
    error: command (git branch --set-upstream-to=HEAD pull/71) failed with non-zero exit status (128)

docs(dotfiles): fix usage example in `portool linkify` help

feat(vim): make K and Esc inside hover window close hover window

Haven't figured out how to close from outside hover window with Escape,
yet.

fix(git): make brown-paper-bag bug fix to menos script

Infinite loops are rad.

refactor(git): reduce coupling between menos and .gitconfig

By just passing the "pattern" right through. Note this assumes non-crazy
patterns, but that's probably ok.

fix(git): avoid annoying breakage of starting "/" in Git pager output

Originally this commit was going to be a different hack to remedy an
annoying problem with `less --pattern=anything +r`, which breaks an
initial "/" on entering the pager (causes it to print "Pattern not found
(press RETURN)").

So, I had code in here to look at our buffer and:

- If there is a match, we know we don't need the "+r", so strip it:
  problem solved!
- If there is no match, we just delete both "--pattern" and "+r".

But I realized that if I just remove all of that (no "--pattern", no
"+r" in our Git "pager.<cmd>" config, and no special handling inside
"menos"), we can rely on our other hack, the one that manipulates the
LESSHISTFILE, to do the trick for us.

Bonus: this stops `less` from highlighting the search pattern as soon as
you hit "j", "k".

The ugly bit: "menos" looks like a generic wrapper, but it isn't really.
It (still) assumes a particular "pattern" is being passed (hence our check for
"commit|diff") and needs to be kept in sync with whatever is in
".gitconfig". A "proper" fix here would make a regexp from the pattern,
but that is made trickier due to the possibility of special characters
like C-k... I still might do that as a follow-up.

fix(dotfiles): update stale list of dotfiles to install

refactor(zsh): drop "S" from LESS environment variable

From "man less":

    -S or --chop-long-lines
          Causes lines longer than the screen width to be chopped (truncated) rather than
          wrapped.  That is, the portion of a long line that does not fit in  the  screen
          width  is  not  shown.  The default is to wrap long lines; that is, display the
          remainder on the next line.

I want this in Git commands, but generally not for general `less` usage.
For example, if I do `less README.md`, I want the lines to wrap so that
I can read it without side-scrolling (Markdown files are often not
hard-wrapped). But if I do `git log -p` I don't want wrapping.

So, move the "S" out of `LESS` and into Git's `core.pager` config. Net
effect is that Git behaves the same as before because it is doing the
equivalent of:

    echo git-command-output | LESS=-iFMRX less -S

instead of:

    echo git-command-output | LESS=iFMRSX less

but the end result is the same.

refactor(vim): make LSP customizations local to buffer

chore(node): actually install preferred TypeScript Language Server

refactor(vim): simplify pinnacle invocation

Requires update to submodule:

* aspects/vim/files/.vim/pack/bundle/opt/pinnacle ad5dde9...2f2ff8e (1):
  > feat: teach pinnacle#decorate() to accept a comma-separated list

fix(vim): make LSP customizations more stable, obvious

Need to hook into `ColorScheme` autocmds to make these stick, because we
re-read out colorscheme whenever we regain focus.

Use underline to make them stand out from normal source code a bit more
(they are already bold and italicized, so this is probably overkill).

feat(vim): make LspDiagnosticsHintSign yellow

In practice, I only see "Error" (eg. "Cannot find name 'JSONValue'") and
"Hint" (eg. "'x' is declared but its value is never read."), so we only
need these two colors.

It's all a bit flakey though, because if I cause Vim to lose focus and
then I come back to it, my highlights get blown away. Not sure whether
that is due to any of my own focus shenanigans though; I'll look into
it.

revert: "feat(vim): add Flow support"

Sadly, couldn't get this to work.

This reverts commit 86b38e5619a27568a18f6d5edd9b0b673cea0fa8.

feat(vim): add Flow support

Seeing as I am still installing the flow-bin package.

Note that I am putting it at the end because I want the TS configuration
to take precedence, although I think it will anyway because of the
defaults which let tsserver handle projects with "package.json" (as well
as "tsconfig.json") whereas they only activate Flow in the presence of
".flowconfig").

fix(vim): stop signcolumn from making things jump around

Just in filetypes that have LSP support.

Otherwise, buffers open and then jump a second later.

fix(vim): don't blow up requiring Neovim things in Vim

refactor(vim): switch to built in Neovim LSP client

Disclaimer: this is very alpha - I am running a "master" build of
Neovim, that may not be stable. Lots of LSP-related activity going on
there now; eg. here is a sample of the latest 20 commits to mention
"lsp", over the last 9 days:

    f605eeec6 lsp: fix tagstack for location jump #12248 (20 hours ago) <Gabriel Sanches>
    2c40a38b3 LSP: Avoid URI-to-fname conversion for non-file URIs #12243 (20 hours ago) <Mathias Fußenegger>
    496b668ad Merge pull request #12237 from h-michael/vim-nil (2 days ago) <Matthieu Coudron>
    67634da71 lsp: add a lsp.util.apply_text_edits test(pending) (2 days ago) <Hirokazu Hata>
    0107a194f lsp: fix apply_text_document_edit test (2 days ago) <Hirokazu Hata>
    501ef9529 lsp: fixup workspace symbol capabilities (#12233) (2 days ago) <Christian Clason>
    d13c1642a Merge pull request #12228 from h-michael/fix-docsyms-to-items (3 days ago) <Matthieu Coudron>
    ea347b18d lsp: add workspace/symbol (#12224) (3 days ago) <Christian Clason>
    2f42e4d0c LSP: Support LocationLink (#12231) (3 days ago) <Christian Clason>
    3eae7d52c lsp: add lsp.util.symbols_to_items test (4 days ago) <Hirokazu Hata>
    d0af0f5c9 lsp: fix lsp.util.symbols_to_items (4 days ago) <Hirokazu Hata>
    6dc839894 [LSP] check for vim.NIL and add apply_text_document_edit tests (4 days ago) <ckipp01>
    42b441738 Merge pull request #12204 from archseer/lsp-user-data (5 days ago) <Matthieu Coudron>
    f9055c585 LSP: enable using different highlighting rules for LSP signs (#12176) (6 days ago) <Ghjuvan Lacambre>
    e4a1be779 lsp/completion: Expose completion_item under completed_items.user_data. (7 days ago) <Blaž Hrastnik>
    e9cc38361 LSP: support tagstack #12096 (7 days ago) <Yen3>
    4e6531ddb lsp: use vim.tbl_isempty to check sign (#12190) (7 days ago) <Hirokazu Hata>
    5f4171783 LSP: don't redefine LspDiagnostics signs #12164 (9 days ago) <jakbyte>
    50ff37308 LSP: Fix show_line_diagnostics #12186 (9 days ago) <Mathias Fußenegger>
    663b83814 LSP: Add a check for null version in VersionedTextDocumentIdentifier (#12185) (9 days ago) <Chris Kipp>

So, while it is super alpha, I think this is the future and it will end
up killing all the user-land LSP plug-ins. There are issues in
LanguageClient-neovim that I doubt will ever be fixed; eg:

- https://github.com/autozimu/LanguageClient-neovim/issues/884
  (September 2019)
- https://github.com/autozimu/LanguageClient-neovim/issues/875
  (mine, August 2019)
- https://github.com/autozimu/LanguageClient-neovim/issues/873
  (mine, August 2019)

Main contributor of the LSP feature remarks:

> It's meant to replace most LSP clients.
>
> The performance benefit is one, and the other benefit is that it's
> got no other dependencies and will come with every neovim instance. I
> also, personally, want it to be the best LSP. I've fixed many
> of the bugs I've come across from other LSPs and I made it very
> extensible. Having it be in the mainline neovim repository means that
> it'll be maintained as long as neovim is maintained, as well.

https://www.reddit.com/r/neovim/comments/dvd8sz/builtin_language_server_with_my_preferred_style/

Some other context:

> In case you missed it, the LSP client was merged into master. In
> order to get users started easily, we have provided this repo with
> configurations for servers that are known.
>
> If you're wondering why this is a separate repo, that's because it is
> changing rapidly and we want users to test this and contribute
> configurations without updating master every time.

https://www.reddit.com/r/neovim/comments/dx098o/github_neovimnvimlsp_common_configurations_for/

As you can see, thanks to https://github.com/neovim/nvim-lsp (official
wrapper), config is way easier.

Bonus: added Vimscript LSP that I learned about from nvim-lsp repo:

https://github.com/iamcco/vim-language-server

Have seen a couple errors so far, but no deal-breakers.

* aspects/vim/files/.vim/pack/bundle/opt/deoplete-lsp 0000000...6aa2bfd (26):
  > Merge pull request #22 from michaeljoelphillips/textedit-bug

* aspects/vim/files/.vim/pack/bundle/opt/nvim-lsp 0000000...534712c (217):
  > [docgen] Update README.md skip-checks: true

docs(fig): correct a typo in a code comment

chore(portool): tweak Gradle build settings again

Seeing as I had two builds take > 60 minutes this morning despite
not making any changes to my setup. I was told to try reducing the
memory used by Gradle. I don't know whether it will help or not, but in
investigating all this I learned:

- I am overwriting my base settings in a dumb way.
- There are many Gradle processes: client, build, daemon, worker, and
  you apparently can't actually control them all in a Liferay build
  environment:
  - Specifically, you can set the memory used by the daemon and the
    build processes, but not the client or the workers.
- `ANT_OPTS` does work to set `ant` VM parameters.
- `GRADLE_OPTS` itself is of dubious use; it may or may not be
  beneficial.
- `JAVA_OPTS` probably does nothing.
- We have default settings in liferay-portal's build.properties file
  that may end up poisoning the gradle/gradle.properties cache anyway,
  so unless you've done a `git clean`, you can't actually be sure that
  changes you make in the environment will have any effect.

Lightweight "proof" that the settings get picked up via `pstree -w -s
java` during an `ant all` (edited for readability):

-+= 00001 root /sbin/launchd
 |-+= 04441 greghurrell tmux new -A -s Corpus
 | \-+= 04869 greghurrell -zsh
 |   \-+= 08272 greghurrell /bin/sh /usr/local/bin/ant all
 |     \-+- 08273 greghurrell java -Xmx8192m -Xms4096m -XX:MaxPermSize=2048m -XX:-UseGCOverheadLimit -Dorg.gradle.jvmargs=-Xmx4096m -Xms2048m -Dorg.gradle.workers.max=4 -classpath /usr/local/Cellar/ant/1.10.5/libexec/lib/ant-launcher.jar -Dant.home=/usr/local/Cellar/ant/1.10.5/libexec -Dant.library.dir=/usr/local/Cellar/ant/1.10.5/libexec/lib org.apache.tools.ant.launch.Launcher -cp  -lib /usr/local/share/ant all
 |       \-+- 09269 greghurrell java -Xmx64m -Xms64m -Dgradle.user.home=/Users/greghurrell/code/portal/liferay-portal/.gradle -Xmx8192m -Xms4096m -XX:MaxPermSize=2048m -XX:-UseGCOverheadLimit -Dorg.gradle.jvmargs=-Xmx4096m -Xms2048m -Dorg.gradle.workers.max=4 -Xmx4096m -Xms2048m -XX:MaxPermSize=2048m -XX:-UseGCOverheadLimit -Dorg.gradle.jvmargs=-Xmx4096m -Xms2048m -Dorg.gradle.workers.max=4 -Xdock:name=Gradle -Xdock:icon=/Users/greghurrell/code/portal/liferay-portal/media/gradle.icns -Dorg.gradle.appname=gradlew -classpath /Users/greghurrell/code/portal/liferay-portal/gradle/wrapper/gradle-wrapper.jar org.gradle.wrapper.GradleWrapperMain --init-script=/Users/greghurrell/code/portal/liferay-portal/modules/init.gradle --parallel -Dbuild.exclude.dirs= -Dbuild.include.dirs= -Dbuild.profile=portal --project-cache-dir=/Users/greghurrell/code/portal/liferay-portal/.gradle --stacktrace -Dapp.server.parent.dir=/Users/greghurrell/code/portal/liferay-portal/../bundles -Dforced.cache.enabled=true -Dliferay.home=/Users/greghurrell/code/portal/liferay-portal/../bundles deploy
 |         \-+= 09297 greghurrell java -Xms2048m -Xmx4096m -cp /Users/greghurrell/code/portal/liferay-portal/.gradle/wrapper/dists/gradle-5.6.4.LIFERAY-PATCHED-2-bin/esuc1lh44aahpvqqbg2zag1ap/gradle-5.6.4/lib/gradle-launcher-5.6.4.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 5.6.4
 |           |--- 09356 greghurrell java -Xmx512m -cp worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Worker Daemon 1'
 |           |--- 09357 greghurrell java -Xmx512m -cp worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Worker Daemon 2'
 |           |--- 09358 greghurrell java -Xmx512m -cp worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Worker Daemon 3'
 |           |--- 09359 greghurrell java -Xmx512m -cp worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Worker Daemon 4'
 |           |--- 09380 greghurrell java -Xmx512m -cp worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Worker Daemon 5'
 |           \-+- 09708 greghurrell node /Users/greghurrell/code/portal/liferay-portal/modules/yarn-1.13.0.js --production false run build
 |             \-+- 09709 greghurrell node /Users/greghurrell/code/portal/liferay-portal/modules/node_modules/.bin/liferay-npm-scripts build
 |               \--- 09711 greghurrell node /Users/greghurrell/code/portal/liferay-portal/modules/node_modules/liferay-npm-scripts/node_modules/.bin/liferay-npm-bundler
 \--= 08446 greghurrell java -Xms2048m -Xmx4096m -cp /Users/greghurrell/code/portal/liferay-portal/.gradle/wrapper/dists/gradle-5.6.4.LIFERAY-PATCHED-2-bin/esuc1lh44aahpvqqbg2zag1ap/gradle-5.6.4/lib/gradle-launcher-5.6.4.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 5.6.4

- `ant` has "-Xmx8g"/"-Xms4g" (as requested).
- That spawns `gradle` client that seems to have "-Xmx64m"/"-Xms64m"
  (no idea how that gets set)
- That spawns another `gradle`, presumably the "build" process, with
  "-Xmx4g"/"-Xms2g" (as requested).
- Various "Gradle Worker Daemon" process all invoked with "-Xmx512m"
  (no idea where that came from).
- Some mysterious other `gradle` process at the bottom; presumably the
  "daemon" itself, with "-Xmx45"/"-Xms2g", again as requested.

Untruncated: https://gist.github.com/wincent/099451e58cd72116c75e7fb4cd958dab

chore: sort .gitmodules

Using usual trick:

```
:%s/\v\n\t/@@@/
:%sort
:%s/\v\@\@\@/\r\t/g
```

docs(fig): include info about Fig's size

This is based on the current contents of the "fig" and "support"
directories, with lines of code counted by the "cloc" tool. Obviously
not a crude tally (for example, ignoring "bin" and "install"), but it
provides a ballpark sense of the size.

docs(fig): fix mangled link

docs(fig): further flesh out with links and explanation

docs(fig): map Fig operations to Ansible modules

docs(fig): fix whitespace damage

docs(fig): state the obvious

docs(fig): show "backup" operation for contrast

refactor(fig): DRY up backup operations with dsl/operations/backup.ts

docs(fig): add disclaimer that Ansible isn't all bad

docs(fig): describe structure and variable access a little more

docs: move some documentation out of a code comment into fig/README.md

docs: fix broken link

fix(meta): make "meta" aspect work irrespective of local umask

test(fig): make tests pass regardless of local umask

fix(fig): make tests pass on Linux

fix(fig): correct case for case-sensitive filesystems

Works fine on APFS because it is a rare beast that, like HFS, opts for
case-insensitivity. Won't work on Linux though. So we have to make the
filename in the source code match the case on disk.

chore(fig): let chown run on Linux

AFAIK, it will work.

feat(fig): teach "stat.ts" to work on Linux

Untested...

docs: remove references to Ansible

chore(defaults): move "macos" out of the root

chore(vim): delete rest of old Vim role

I am lazily not porting everything over yet but leaving it as a "TODO"
because I want to revisit to determine for sure which packages are
actually needed. And I don't think I want `update-bundle` to ever be
called as part of normal runs, so I will probably never implement that.

chore(dotfiles): move rest of "dotfiles" role over to aspect

chore(misc): kill off "misc" role

No longer using this avatar, and no longer have an "~/Archives" folder.

refactor(cron): move "~/mbox" management into "cron" aspect

Kind of fits there, and don't want to have "misc" hanging around.

feat(fig): create "ruby" aspect

Thought about making a "gem" operation but it would obviously be
overkill.

fix(vim): avoid error on /usr/bin/vim startup

chore: remove chruby and ruby-install

I am too old to be messing with Ruby versions; doing a search for
`.ruby-version` files on my disk, I find only legacy projects that are
asking for ancient versions (eg. 2.1.3, which came out 6 years ago). I
have been sticking with the system-provided Ruby quite happily for a
while now).

feat(node): install global packages

"Global" in the sense that they go into `~/n`.

Not sure if there are any chicken-and-egg problems with respect to
Neovim, but even if there are, they probably don't run very deep (ie. I
am not using and JS-based plug-ins at this time; only stuff that
interacts indirectly with the rig, like typescript-language-server).

fix(karabiner): avoid chicken-and-egg dependency on node

Don't want to have to rely on "node" having been previously installed
and available in the path. Use the `bin/node` wrapper script instead,
which we know must be present in order for us to be running at all.

This means that even on the first run (before `$PATH` includes an active
installed entry under `~/n`) that we can use Node here.

feat(fig): add "node" role

refactor(karabiner): move helpers into ~/bin

Because it is simpler. They don't need to be templates any more, and we
loosen the interdependency between the dotfiles and karabiner aspects.

refactor(fig): move Karabiner helper scripts into "karabiner" aspect

This is better in the sense that the related things now go together, but
there is some ugliness because the files live in `~/.zsh/bin`, which is
managed by another role.

So, we use templates so that we can avoid mistakes with accidental edits
(via a `figManaged` "nomodifiable" setting), and we `.gitignore` the
file so that Git only sees the source, not the output.

Now, I could stick this in some other directory, but I'd still need to
modify the `$PATH` for completeness. I might still to that. Basically,
make `~/.path.d/` directory and allow any role to add to it. There'd
still be a dependency there, but it would be less ugly (as in, wouldn't
need to use templates or `.gitignore`). The helper scripts here, then,
could live anywhere I want: like, say, `.config/karabiner/bin`.

refactor(karabiner): convert binary AppleScript to text

chore(fig): move `dry` build and setup into "karabiner" aspect

chore(fig): move two encrypted files from old "dotfiles" role

chore(fig): port .hammerspoon/iterm.lua templating to Fig

chore(fig): migrate .gemrc from Ansible role to Fig aspect

chore: drop references to http_proxy

I haven't been forced to use a proxy since I left FB, so let's just get
rid of the clutter here.

docs: update CHANGELOG.md

Note the entry about dropping Ansible dependency. I already deleted it a
few days back, and I am pretty sure I will have moved the remaining
pieces by the end of the day.

chore: remove Mutt config

Not because Mutt and these other tools are bad; just because I haven't
used Mutt for well over a year now. Main reason: new job uses the Google
Suite (Gmail, calendars, Drive etc), and the value of the integration
there is such that I am better off just using the Gmail web client. I
barely use personal email at all, so I end up just using the same for
personal email as I do for work email. So, that means, Gmail for
everything. When I used to work at FB (where we didn't use Google
products because they were our enemies -- ha) the calculus was different
and I was happy using Mutt for everything.

This doesn't have to be a one-way street. The code is still all in the
repo history if I ever want to go back to Mutt again.

chore(vim): update dirvish submodule

To get fix for: https://github.com/justinmk/vim-dirvish/issues/173

* aspects/vim/files/.vim/pack/bundle/opt/vim-dirvish 7563e4c...a197607 (2):
  > FileType handler must not change the current window #175
  > Preserve literal backslashes on non-Windows #174

refactor(fig): port "ssh" role to Fig

refactor(fig): make "backup" role actually do something

Albeit, not much.

chore(backup): update backup paths in "snapshot" script

refactor(fig): move "backup" role files to "aspects/backup"

As noted inline, this aspect doesn't actually do anything; it just
provides us with a place to store and version-control some files of
interest. Maybe one day it will actually do something.

feat(vim): add syntax highlighting for AppleScript

Although I really hope I don't have to use it all that often... #crying

refactor(fig): store "Open in Terminal Vim.js" as separate file

So that it is easier to change an edit. As simple as figuring out how to
trick AppleScript into reading a file (ie. 30 minutes of Googling, and
in the end, the problem was my variable name, "script", was leading to
an indecipherable error message).

feat(fig): port "fonts" role to Fig

And make it an actual-op aspect instead of a no-op manual role.

style(fig): normalize whitespace

No mixed tabs/spaces here (these were created by Apple's ScriptEditor
app).

docs(fig): remove stale "no-op" claim

feat(fig): turn automator into "real" aspect

Now we use AppleScript to tell Automator to create an app that runs
AppleScript. This probably would have taken an AppleScript expert a few
minutes, but it took me a few hours, because AppleScript is a read-only
language (ie. writing it is stupidly hard; the "natural" syntax is a
deceit).

chore(fig): port automator "role"

Doesn't actually do anything, but maybe I will be able to, er, automate
this in the future.

Note that because I don't have this aspect listed in the project.json,
even if you run `./install automator`, it won't even print the "skip"
message because it does literally nothing. Consider this aspect
aspirational and a placeholder.

Also note the bad filename of the old file; I don't think I had a good
reason for this -- it was almost certainly a mistake.

feat(fig): port "shell" role to Fig

Very simple "line" operation here, a subset of Ansible's "lineinfile"
functionality.

feat(fig): finish porting "iterm" role

refactor(git): try to make .lesshst corruption less likely

OS will probably ignore this, but just in case it helps going to do it
anyway.

fix(git): correct order of command and parameter

refactor(menos): note weird behaviors when invoked by Git

All of these seem to happen to `less` as well, and require `--pattern`
to be in effect, and only when in a pipeline managed by Git (ie. I can't
repro with commands like `cat something | menos`.

fix(menos): forward CTRL-C to less

Something a bit fishy here still. In naked `less`, for example, CTRL-C
doesn't do anything unless `-K` is passed (in which case it exits).

In `menos`, it turns off line numbers... But only when used as a pager
from Git; it behaves the same here:

    cat /etc/passwd | less -iFMRSX
    cat /etc/passwd | menos -iFMRSX