doc: update brew package name

Fix usage information in bin/{get,put}

Allow hyphens in plug-in names

Discovered the need for this while extracting the vcs-jump plug-in.

tmux: fix resizing issues

Caused by: https://github.com/tmux/tmux/commit/dbc8cae18cabcd

Update Ferret fixture files

Allow bang in command names

Maybe this should be stricter, only allowing it at the end.

Properly handle UTF-8 in tests

Closes: https://github.com/wincent/docvim/issues/37

Update golden files

Update Ferret fixtures

Add additional blank line above headings

To pacify GitHub's new Markdown parser.

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 0.3.2.1 release

Update Loupe fixtures

Add missing fixture file to distribution

Fixes: https://github.com/fpco/stackage/issues/1648

Prepare for 0.3.2.0 release

Don't bother with lts-3 and lts-5 builds

These will fail; eg:

- https://travis-ci.org/wincent/docvim/jobs/139231414
- https://travis-ci.org/wincent/docvim/jobs/139231416

Because a recent version of hlint (not available in the old lts snapshots) is
required in order to do CPP conditionals properly; see:

- https://github.com/ndmitchell/hlint/issues/239

Make Control.Applicative imports conditional

May eventually want to go with a Prelude wrapper like this:

https://github.com/jgm/pandoc/blob/09b4f294bf4584f00/prelude/Prelude.hs

But starting simply for now.

Print function annotations

This is pretty rough, but I need to start documenting these in Loupe. May
change. For example, I might want to parse and use argument lists.

Includes Loupe fixtures update.

Prepare for 0.3.1.6 release

Motivated by:

- https://github.com/fpco/stackage/pull/1618
- https://github.com/fpco/stackage/commit/ac5e11ac80f757ebccbf173ab7b2a8a7169e2572

Add sdist and upload scripts

Which I meant to include in the last commit.

Prepare for 0.3.1.5 (signed release)

Prepare for 0.3.1.4 release

Try using --pvp-bounds both

Squash of `bounds` branch:

- https://github.com/wincent/docvim/tree/bounds
  (commit 22e92335248334b33d791c179b25fc53a16aafb2)

Based on discussion here:

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

Trying this:

- (Almost) no constraints in docvim.cabal file.
- Upload using --pvp-bounds, which produces a docvim.cabal file something like
  this: https://gist.github.com/wincent/145d35bbc75cff2a491fd33fe81d39b0

This effectively means we'll upload something more constrained than what we
tested in Travis, and that is probably OK.

Note that I had to add base upper bounds as noted here:

  https://travis-ci.org/wincent/docvim/jobs/138374403

> ++cabal check
> The following errors will cause portability problems on other environments: *
> The dependency 'build-depends: base' does not specify an upper bound on the
> version number. Each major release of the 'base' package changes the API in
> various ways and most packages will need some changes to compile with it. The
> recommended practise is to specify an upper bound on the version of the 'base'
> package. This ensures your package will continue to build when a new major
> version of the 'base' package is released. If you are not sure what upper
> bound to use then use the next major version. For example if you have tested
> your package with 'base' version 2 and 3 then use 'build-depends: base
> >= 2 && < 4'.
>
> Hackage would reject this package.

See also:

  https://github.com/commercialhaskell/stack/issues/2262

Switch Stack resolver back to lts

As recommended here:

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

Prepare 0.3.1.3 release

Add another explicit Control.Applicative import

Should fix this:

https://travis-ci.org/wincent/docvim/jobs/138266318

Disable stack 7.8.4 builds in Travis

These are always doomed to fail, unless I backport `cosmosOf`.

Sample failures:

- https://travis-ci.org/wincent/docvim/jobs/138265665
- https://travis-ci.org/wincent/docvim/jobs/138265670

> /home/travis/build/wincent/docvim/lib/Text/Docvim/AST.hs:135:19: Not in scope:
> ‘cosmosOf’

`cosmosOf` was added in lens 4.11.1, and this version of stack has 4.7.0.1.

Add another explicit Control.Applicative input

To fix build bustage like this one:

https://travis-ci.org/wincent/docvim/jobs/138265053

Fix lint

Only happens in CI here:

    https://travis-ci.org/wincent/docvim/jobs/138121738

Quoting:

    lib/Text/Docvim/Visitor.hs:52:26: Warning: Redundant bracket
    Found:
      (a -> m c) -> (a -> m b)
    Why not:
      (a -> m c) -> a -> m b

    lib/Text/Docvim/Visitor.hs:52:55: Warning: Redundant bracket
    Found:
      (b -> m c) -> (a -> m c)
    Why not:
      (b -> m c) -> a -> m c

Explicitly import <$> from Control.Applicative

To hopefully fix this build error:

https://travis-ci.org/wincent/docvim/jobs/138121730

Without introducing any other build failures...

Try relaxing lower bound of base dependency to 4.6

To see if it fixes some CI failures, or exposes new ones:

https://travis-ci.org/wincent/docvim/builds/138094055

Use sorting to produce stable ASTs

I think we're falling prey to inode iteration order issues, meaning that our AST
is not always the same, depending on which system we run on.

Example failure:

https://travis-ci.org/wincent/docvim/jobs/138109029

Should be fixed by always visiting the files in the same order.

Fix for HFS+ brain-deadness

Case-insensitivity strikes again. I suspect this will fix some build failures.
See:

https://github.com/wincent/docvim/issues/24

Defer type errors in REPL

- https://www.reddit.com/r/haskell/comments/4np0l2/a_ghci_annoyance_wondering_if_anyones_else_also/
- https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/defer-type-errors.html

Don't use -Werror in Stack

I intend this to mostly be a local feedback tool, so I *think* that defaulting
this to off is right call. I fixed the specific build failure cited below anyway
in c9efe9d7b010adbd1, but I think it's ok to turn off `-Werror` in Stack because
other "real" errors will still be errors; these are just warnings.

I've added explicit `-Werror` to all my wrapper scripts except `bin/repl`, which
is not "build-like" and I want to be lenient. (I actually meant to make it more
lenient in the future by deferring type errors with `-fdefer-type-errors`.

See:

- https://github.com/wincent/docvim/issues/24
- https://travis-ci.org/wincent/docvim/jobs/138094062
- https://www.reddit.com/r/haskell/comments/4np0l2/a_ghci_annoyance_wondering_if_anyones_else_also/

Tweak Control.Lens import for better compatibility

One of the CI runs blowing up:

    /home/travis/build/wincent/docvim/lib/Text/Docvim/Optimize.hs:3:1: Warning:
        Module ‘Control.Lens’ does not export ‘Empty’
    <no location info>:
    Failing due to -Werror.

Source: https://travis-ci.org/wincent/docvim/jobs/138094062

I'm going to turn off `-Werror` in CI and keep it locally, but in the meantime I
think I can get compatibility with a wider range of Lens versions if I switch
the import to not mention `Empty`.

See also: https://github.com/wincent/docvim/issues/24

Remove cabal.config

I had added this in 9b8d1674510ab57a530c7aba8bba0c7dbb3b0207 in order to get
reproducible builds, before switching to Stack. But it is causing Travis CI
build failures (eg. https://travis-ci.org/wincent/docvim/jobs/137999458), so
let's remove it: Stack should give me the reproducibility I need.

Prepare for 0.3.1.2 release

Add missing fixture files

As noted in this issue, tests are failing because these fixtures are not
included:

  https://github.com/wincent/docvim/issues/25

Add README badges for Travis CI and Stackage

Add .travis.yml

From:

  http://docs.haskellstack.org/en/stable/GUIDE/#travis-with-caching

More context:

  https://www.fpcomplete.com/blog/2016/02/updated-haskell-travis-config

Similar sample from pandoc:

  https://github.com/jgm/pandoc/blob/master/.travis.yml

Provide instructions for installing via Stack

I think this should work now, or soon at least, thanks to:

https://github.com/fpco/stackage/commit/b6eb03bf6b6de1083567eb69a9cfdb67ea6a184b

Update CHANGELOG

Reintroduce base upper bound, but make it more lenient

Because `cabal check` informs me that Hackage would reject it.

Prepare 0.3.1.1 for release

Having tested compatibility with GHC 8.0.1.

Relax base dependency

Hopefully this is loose enough. Tested by updating to latest nightly resolver in
the stack.yml file, then:

```
stack build
bin/test
bin/lint
bin/docvim -h
```

For additional context:

https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds

Update to latest Stack lts version (5.9 -> 6.3)

Tested with `stack build`. It works.

Move footer content down to footer

Update Loupe fixtures

Special-case empty output

Don't print a blank-line, prefer a zero-byte file.

Closes: https://github.com/wincent/docvim/issues/21

Add loupe files to integration tests

Add vim-clipper to integration tests

Add Terminus to the integration tests

This is a good one as we don't have any doc comments. Should produce empty
files, but produces files with a blank line.

Add Command-T files to integration tests

And yay, we've exposed a bug. Note that Command-T isn't
at all docvim-ready yet (no doc comments) but we still
shouldn't blow up trying to process it.

Teach bin/get to grab from HEAD, not master

Seeing as Command-T is usually pointing at next, for example, and I don't want
to add the complexity of special-casing this at this point.

Add Pinnacle to integration tests

Fix gitignore

To actually ignore the files I (don't) care about.

Attempt workaround for cyclic update issue

On the one hand, I like the simplicity of keeping all
the files in the input dirs (and also the fact that it
exercises the logic that targets only .vim files), but
I don't want to deal with cyclic updates, so let's just
pretend these files don't exist.

Add vim-docvim to integration tests

Update integration test files

Evidently, we have a circular dependency here. You update the
input files, get new output, copy the output over to the
other repo, commit it there, and now your input files have
changed. Not too worried about this, but it would be nice to
find a neat way to avoid the issue.

Get changelog ready for master development

Add missing changelog updates

Prepare for 0.3.1.0 release

Squelch warning

> Exposed modules use unallocated top-level names: Paths_docvim

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

Get back -Werror, at least when running via Stack

This seems the easiest way to get the behavior I desire, seeing as I only ever
run stuff via Stack, but this won't block package uploads to Hackage.

Start new changelog section

Don't use Werror

Otherwise, I can't upload a package:

> Invalid package
>
> 'ghc-options: -Wall -Werror' makes the package very easy to break with future
> GHC versions because new GHC versions often add new warnings. Use just
> 'ghc-options: -Wall' instead. Alternatively, if you want to use this, make it
> conditional based on a Cabal configuration flag (with 'manual: True' and
> 'default: False') and enable that flag during development.

Update CHANGELOG prior to 0.3.0.0 release

Add bin/get and bin/put for updating integration tests and downstreams

Remove useless script

Those tests don't exist any more, so no need to update them.

Fix explicit links to GitHub headings

Not sure whether I want to apply this to h3 or just h1/h2, but for now doing it
to all headings.

Closes: https://github.com/wincent/docvim/issues/3

Get rid of ugly ast, ast2, ast3 etc bindings

The replacement is pretty ugly too, so will look at refactoring further.

Closes: https://github.com/wincent/docvim/issues/11

Fix indent

Remove redundant integration tests

This and more now covered by tests/fixtures/integration.

Closes: https://github.com/wincent/docvim/issues/10

Add parser tests to integration tests

Update changelog

Want to get into the habit of doing this early and often.

Filter out Empty nodes

I wanted (want) to do this in a more generic way, but I first figured I would do
this "manually" using pattern matching and explicit constructors. Will keep
looking thought to see if there is something in `Control.Lens` or `Data.Data`
that would help me do this.

Closes: https://github.com/wincent/docvim/issues/9

Add file meant to be included in previous commit

Partial implementation of pruning empty paths

Partly addresses: https://github.com/wincent/docvim/issues/9

Fix jumbled sections

Injected headings were not getting correctly extracted because they didn't
appear inside `DocBlock`s.

Closes: https://github.com/wincent/docvim/issues/8

Fix style by camel-casing

Fix case for Vim help plugin header

Always lower. And no need to be in the symbol table because the Vim printer
doesn't even consult it.

Center plugin header

Or "justify", if you prefer.

DRY

DRY up the integration tests

Add Vim help integration tests

With the magic of copy-pasta. Will refactor away the duplication presently.

Indentation

Add (Markdown) integration tests

Plaintext to follow. Just need to figure out a way to do it cleanly.

Add integration test files

Copied into place with:

git --git-dir ~/code/ferret/.git archive --prefix=ferret/input/ master | tar -x -C tests/fixtures/integration -f -
git --git-dir ~/code/scalpel/.git archive --prefix=scalpel/input/ master | tar -x -C tests/fixtures/integration -f -

Will add more of these, I guess, as I start using docvim in more places.

More misguided refactoring

Start refactoring golden tests to support end-to-end testing

Show compiled AST when debug flag is set

Remove a stale comment

Fix remaining lint about duplication

First lint-free status in months. Yay.

Make linter happier about duplication

Still not entirely happy.

Add bin/clean script

Add bin/build script and use it

Fix remaining warnings

Which means we can turn -Werror back on.

Made sure to get a full rebuild with:

```
rm -rf .stack-work/dist/*
bin/build # really just `stack build --file-watch`
bin/lint
bin/test
```

Further improve type annotations

Improve Parse.hs type signatures

With the help of:

http://stackoverflow.com/questions/37739029/understanding-parsec-type-annotations

Now warning-free.