The Haskell code uses tabs for indentation, and displays well with
tab-width set to 2. So, I created a .dir-locals.el (applies to all
files opened in emacs at or below ./), which sets 'tab-width' to 2,
turns on 'indent-tabs-mode', and highlights leading spaces in
'haskell-mode'.
The creation of the 'git-annex-shell' symlink was in 'postInst' hook.
I combined it with the man-page installation in a 'postInst' hook and
a 'postCopy' hook. I don't understand how to use the `cabal copy`
command, but the examples I looked at defined both hooks.
Relevant comments from the source:
* man-page installation:
See http://www.haskell.org/haskellwiki/Cabal/Developer-FAQ#Installing_manpages.
Based on pandoc's and lhs2tex's 'Setup.installManpages' and
'postInst' hooks.
My understanding: 'postCopy' is run for `cabal copy`, 'postInst' is
run for `cabal inst`, and copy is not a generalized install, so you
have to write two nearly identical hooks.
Summary of hooks:
http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-Simple-UserHooks.htm--
Other people are also confused:
* Bug: 'postCopy' and 'postInst' are confusing:
http://hackage.haskell.org/trac/hackage/ticket/718
* A cabal maintainer suggests using 'postCopy' instead of
'postInst', because `cabal install` is `cabal copy` followed by
`cabal register`:
http://www.haskell.org/pipermail/libraries/2008-March/009416.html
Although that sounds desirable, it's not true, as the reply and
experiments indicate.
* the `cabal copy` command:
???: Not sure how you're supposed to use this. E.g., when I do
cabal install --prefix=/tmp/git-annex-install
cabal copy --deistdir=/tmp/git-annex-copy
I get the copy under
/tmp/git-annex-copy/tmp/git-annex-install
Also, `cabal install` fails when given a relative --prefix.
While I was in there, I noticed and fixed a bug in the queue size
calculations. It was never encountered only because Queue.add was
only ever run with 1 file in the list.
This ensures that all special remotes show up in git annex status.
Before, a special remote that was not manually described, and was not
a current git remote, did not show up there, although initremote did list
it.
There's a race adding a new file to the annex: The file is moved to the
annex and replaced with a symlink, and then we git add the symlink. If
someone comes along in the meantime and replaces the symlink with
something else, such as a new large file, we add that instead. Which could
be bad..
This race is fixed by avoiding using git add, instead the symlink is
directly staged into the index.
It would be nice to make `git annex add` use this same technique.
I have not done so yet because it currently runs git update-index once per
file, which would slow does `git annex add`. A future enhancement would be
to extend the Git.Queue to include the ability to run update-index with
a list of Streamers.
