chore: add .mailmap

Because I just foolishly pushed a commit from my work machine without
first having run `git config user.email` for this repo.

fix: also work with long forms of `:v` (`:vg` ... `:vglobal`)

Don't know what I was thinking, but I didn't ship the complete fix in
a0057f55c0e8c3067811c4e1ce4e2f1eb2ea8e57. This commit adds this missing
forms of the `:v` command.

fix: make `:g!` work as a command

This is a little bit subtle, but I tried to explain it in the comments.
Turns out that `:g!` (and `:gl!`, `:glo!` ... `:global!`) is a command,
equivalent to `:v`, and Vim _does not_ treat the `!` as a slash
delimiter. This means that the old behavior was wrong; we would see `!`
after the `:g`, assume it was a delimiter, and append `!\v`. Instead,
what we need to do, is leave it unexpanded and wait for the user to
input a slash (or other delimiter).

Summarizing - standard usage with a slash:

- `:g/foo/d` means "delete all lines matching foo".
- `:v/foo/d` means "delete all lines not matching foo".
- `:s/foo/bar/` means "replace foo with bar".

And you can use lots of other symbols in lieu of slash, like "#":

- `:g#foo#d` means "delete all lines matching foo".
- `:v#foo#d` means "delete all lines not matching foo".
- `:s#foo#bar#` means "replace foo with bar".

But "!" is special, because sometimes it indicates a bang form of a
command and other times it can stand in for slash:

- `:g!/foo/d` means "delete all lines not matching foo"
  (ie. Vim treats this as a valid bang command).
- `:v!foo!d` is an error, because there is no `:v!` command
  (ie. Vim rejects this as an invalid bang command).
- `:s!foo!bar!` means "replace foo with bar"
  (ie. Vim does _not_ consider this a bang command, and treats "!" as a
  delimiter).
- `:g!!foo!d` means "delete all lines not matching foo"
  (ie. Vim treats this as a valid bang command _and_ treats the second
  and third "!" as delimiters).

Makes sense?

I thought so...

Updated docs with:

    bin/docvim -c ~/code/loupe ~/code/loupe/doc/loupe.txt ~/code/loupe/README.md -v

Closes: https://github.com/wincent/loupe/issues/20

refactor: edit some code comments in the name of precision

We're using "slash" in an abstract sense here to mean "delimiter" (in
fact, as I write this, I wonder whether we should just use that word...
🤔), so we shouldn't use a literal "/" in the comments.

fix: make `g:LoupeVeryMagic` work with `:su`, `:sub`, `:subs` etc

Previously we were only looking for `:s`, `:g` and `:v`, but we should
actually work for all the non-abbreviated forms too.

Noticed while investigating:

    https://github.com/wincent/loupe/issues/20

Seeing as I've blown away my Haskell-based docvim install
on this machine (my personal laptop) while working on the
new-but-not-yet-feature-complete Rust-powered version, I
needed to set up a new install in order to update the docs:

    git clone $REPO_URL docvim-haskell
    cd docvim-haskell
    bin/build
    bin/docvim -c ~/code/loupe ~/code/loupe/doc/loupe.txt ~/code/loupe/README.md -v

chore: move "master" → "main"

docs: fix broken heading rendering

By using latest docvim:

    https://github.com/wincent/docvim/commit/8f9d1f00d494b753fd212a1baf42ad00a3c9e286

Built using:

    (cd ~/code/docvim && bin/docvim ~/code/loupe/doc/loupe.txt ~/code/loupe/README.md -c ~/code/loupe -v)

doc: work around GitHub Markdown formatting quirk

By regenerating with this commit applied:

https://github.com/wincent/docvim/commit/929ccc20b70a712918a06308a10ac493e65a91f2

doc: try to make overrides section "headings" stand out a bit more

feat: add g:LoupeCaseSettingsAlways

Fixes an annoyance I've long had with `*`, `#` etc; it doesn't respect
'ignorecase' and 'smartcase' settings. It behaves as if 'ignorecase' and
'nosmartcase' were always in effect, unlike `/` and `?`.

In this commit we add a new setting, on by default, that makes all of
the search mappings behave the same, respecting the value of
'ignorecase' and 'smartcase'.

Also as noted in the comments, we take the opportunity to enhance a very
edge-casey thing: that if you have a special char like "\" in your
'iskeyword' setting, then `*` won't work when the cursor is on a `cword`
like "foo\bar". We can fix that with some escaping, seeing as we're
bypassing the whole `*`/`#` mechanism anyway.

Freshened the docs with the following (because my Haskell environment is
horrendously broken on this machine):

dist-newstyle/build/x86_64-osx/ghc-8.4.4/docvim-0.3.2.1/x/docvim/build/docvim/docvim \
  -c ~/code/loupe -v \
  ~/code/loupe/doc/loupe.txt ~/code/loupe/README.md

doc: rebuild with tweaked docvim to make function heading stand out

Prepare for v1.2.2 release

Ensure E802|E803 is caught regardless of 'iskeyword'

Regen documentation

To pacify GitHub's new Markdown parser, regen the documentation using a
newer version of docvim; specifically, we need this commit:

https://github.com/wincent/docvim/commit/4c855ae060f37c775527df3d93ee0f18a9ffef79

Don't allow bad search patterns to print ugly errors

This will stop Vim from freaking out when we end the user searches with
`/\v*` and we end up passing a pattern like `\c\%#\v*` to `matchadd()`.

Closes: https://github.com/wincent/loupe/issues/13

Add empty .watchmanconfig

Allows a Watchman instance configured with `enforce_root_files` to watch
this directory even if `root_files` does not contain any of the files in
the directory. (Necessary to get around undesired corporate
`/etc/watchman.json` config.)

Prepare for 1.2.1 release

Open folds when jumping to a match

Folds aren't opening due to some unknown Vim quirk; perhaps there is some
conditional logic in there that prevents the default behavior from happening in
the context of a mapping. Whatever the case, adding an explicit `zv` gives us
the same effect as the default behavior.

Fixes: https://github.com/wincent/loupe/issues/9
Thanks to @adriaanzon for the report and for suggesting the fix.

Update docs for 1.2 release

DRY up :noh overrides

Tested every which way and seems to work pretty well.

Make fix even better

Gets rid of unwanted rightwards movement.

Improve the :noh<space> fix

I had it written like this initially but didn't like it
because of some unwanted space movement behavior which
I couldn't seem to overcome with <Left>, so I tried the
version shipped in the last commit. Turns out this is
better, even if it is not perfect. Moves the cursor to
the right on each run, instead of to the second column.
Still sucks, but it is less jarring.

Slightly improve behavior of ":noh<space>"

If you hit ":noh<CR>" you get ideal behavior.
If you hit ":noh<Space>" before this commit, you got nothing until you hit space
again.
With this commit, ":noh<Space>" behaves like ":noh<CR>" (triggers side-effect).

This still isn't ideal, but it is better than it was before.

Warts:

- This is a hack: all we really want is the ability to run a callback when the
  real `:noh` is called.
- Hitting <Space> and have it trigger a side-effect is a smell.
- We still get undesired cursor movement: <CR> moves to the start of the current
  line in the buffer, and then we get a one-char bump the right, even if I
  attempt compensatory cursor movements.

Suppress unwanted cursor movement on `:noh<cr>`

I noticed that given:

    :cabbrev foo echo "foo"

That `:foo<space>` would produce `:echo "foo" ` (note the trailing space) but
`:foo<cr>` would not, and nor would it trigger any unwanted cursor movement in
the current buffer.

With this change, we get that same behaviour: `:noh<space>` will act a bit
weird, but who uses that? At least `:noh<CR>` does the right thing.

Switch from cabbrev to more conservative cnoreabbrev

Seems safer.

Avoid unwanted cabbrev

Our mapping ends up expanding `:nohlsearch<CR>` thanks to `:cabbrev` as follows:

    cabbrev <silent> <expr> nohlsearch
    (getcmdtype() == ':' && getcmdpos() == 11 ?
    'nohlsearch <bar> call loupe#private#clear_highlight()<CR>' : 'nohlsearch')

This has two undesired effects:

- It means `loupe#private#clear_highlight()` gets called twice.
- It inserts an unwanted `<CR>` due to this behavior noted in the help (`:h
  abbreviations`):

> The non-keyword character which ends the abbreviation is inserted
> after the expanded abbreviation.

ie. the cursor moves whenever I hit `<leader>n`. Ugh.

Fix that by using `<bar>` and avoiding the expansion of the abbreviation.

Add missing heading formatting

Regenerate docs with docvim 0.3.2.0

Regenerate docs

Make loupe#private#hlmatch not private

So that people can compose this to make custom mappings of their own. See:

  https://github.com/wincent/loupe/issues/7

Not sure this is the sort of API that I really want to commit to supporting
forever (hence why it was previously private), but ¯\_(ツ)_/¯

Make it possible to suppress *, #, n, N, g*, g# mappings

Part of addressing:

  https://github.com/wincent/loupe/issues/7

Introduce s:map()

Wrapping this inside a function so that I can address:

https://github.com/wincent/loupe/issues/7

in exactly one place.

Prepare for 1.1 release

Make compatible with older Vim (missing v:hlsearch)

Addresses:

  https://github.com/wincent/loupe/issues/6

Of the two possible fixes to apply when `v:hlsearch` is not available:

- Clear unconditionally.
- Never clear.

went with the former as it feels like a better user experience. You can always
get the highlight back by hitting "n" or "N".

Add support for non-/ delimiters

Fixes bug noted in: https://youtu.be/Ipkn3tXKrrA

doc: Make overriding overrides instructions more obvious

In response to:

https://github.com/wincent/loupe/issues/5

I had documentation in here already, but it is not very obvious, so let's make
it stand out with a heading.

doc: Move footer content down to footer

Add docvim-generated documentation

Prepare source code for documentation generation via docvim

Tweak README headings to avoid repetition

Replace plaintext README with Markdown

doc: add DEVELOPMENT section

This is a copy-pasta from Ferret, and the same as I have in Terminus.

Update docs for 1.0 release

I think we're stable at this point so we might as well call this 1.0.

Merge branch 'pull/3'

Originally submitted at: https://github.com/wincent/loupe/pull/3

* pull/3:
  Avoid E802

Avoid E802

Similar to 156f62c3, we are not entirely sure why this might happen, but
the cost of guarding against it is low. `:h E802` and `:h E803` bring up
the same section, so the root cause is likely similar or the same.

I decided to use a more verbose regex than necessary to make it easier
to search for this line in the code.

Fixes #1

doc: Fix duplicate tags

The `loupe-history` tag appears twice in the file, which can cause:

> E154: Duplicate tag "loupe-history" in file

Rename the `loupe-history` tag in the OVERRIDES section to
`loupe-history-override` to resolve the clash, and change the other
tags in the section to follow the same `*-override` pattern for
consistency.

Closes: https://github.com/wincent/loupe/issues/2

Avoid E803

We're not sure exactly why this might happen, but the cost of guarding
against it is low.

Should fix https://github.com/wincent/loupe/issues/1

doc: Add RELATED section

Use get() to get optional values with defaults

Via Pro-Tip at: https://github.com/wincent/ferret/issues/5

Add LICENSE.txt

doc: add link target for <Plug>LoupeClearHighlight

So that people can still find it if they search for it under the old
name (and they might, because I've linked to it from the HISTORY
section).

Rename <Plug>LoupeClearHighlight to <Plug>(LoupeClearHighlight)

Which I just learned to be best practice via:

http://stackoverflow.com/a/13698530/2103996

Fix tiny misalignment in the help docs

Doc: add missing blank line

We use two blank lines at the end of each section.

Apply style fixes

Prefer `let l:foo=1` over `let l:foo = 1`, for consistency with the
style we've pretty much always followed for `set` calls.

doc: Correct error in submodule set-up instructions

Rename loupe.txt to README.txt so that GitHub can find it

Update docs

Note 0.1 release date in HISTORY section.

Add WEBSITE section.

Add top-level .gitignore

Initial import

From b26099ef7882 in my dotfiles repo
(https://github.com/wincent/wincent).