b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
92 lines
2.8 KiB
Markdown
92 lines
2.8 KiB
Markdown
If you do nothing else, avoid use of partial functions from the Prelude!
|
|
`import Utility.PartialPrelude` helps avoid this by defining conflicting
|
|
functions for all the common ones. Also avoid `!!`, it's partial too.
|
|
|
|
Use tabs for indentation. The one exception to this rule are
|
|
the Hamlet format files in `templates/*`. Hamlet, infuriatingly, refuses
|
|
to allow tabs to be used for indentation.
|
|
|
|
Code should make sense with any tab stop setting, but 8 space tabs are
|
|
the default. With 8 space tabs, code should not exceed 80 characters
|
|
per line. (With larger tabs, it may of course.)
|
|
|
|
Use spaces for layout. For example, here spaces (indicated with `.`)
|
|
are used after the initial tab to make the third test line up with
|
|
the others.
|
|
|
|
when (foo_test || bar_test ||
|
|
......some_other_long_test)
|
|
print "hi"
|
|
|
|
As a special Haskell-specific rule, "where" clauses are indented with two
|
|
spaces, rather than a tab. This makes them stand out from the main body
|
|
of the function, and avoids excessive indentation of the where cause content.
|
|
The definitions within the where clause should be put on separate lines,
|
|
each indented with a tab.
|
|
|
|
main = do
|
|
foo
|
|
bar
|
|
foo
|
|
where
|
|
foo = ...
|
|
bar = ...
|
|
|
|
Where clauses for instance definitions and modules tend to appear at the end
|
|
of a line, rather than on a separate line.
|
|
|
|
module Foo (Foo, mkFoo, unFoo) where
|
|
instance MonadBaseControl IO Annex where
|
|
|
|
When a function's type signature needs to be wrapped to another line,
|
|
it's typical to switch to displaying one parameter per line.
|
|
|
|
foo :: Bar -> Baz -> (Bar -> Baz) -> IO Baz
|
|
|
|
foo'
|
|
:: Bar
|
|
-> Baz
|
|
-> (Bar -> Baz)
|
|
-> IO Baz
|
|
|
|
Note that the "::" then starts its own line. It is not put on the same
|
|
line as the function name because then it would not be guaranteed to line
|
|
up with the "->" at all tab width settings. Similarly, guards are put
|
|
on their own lines:
|
|
|
|
splat i
|
|
| odd i = error "splat!"
|
|
| otherwise = i
|
|
|
|
Multiline lists and record syntax are written with leading commas,
|
|
that line up with the open and close punctuation.
|
|
|
|
list =
|
|
[ item1
|
|
, item2
|
|
, item3
|
|
]
|
|
|
|
foo = DataStructure
|
|
{ name = "bar"
|
|
, address = "baz"
|
|
}
|
|
|
|
Module imports are separated into two blocks, one for third-party modules,
|
|
and one for modules that are part of git-annex. (Additional blocks can be used
|
|
if it makes sense.)
|
|
|
|
Using tabs for indentation makes use of `let .. in` particularly tricky.
|
|
There's no really good way to bind multiple names in a let clause with
|
|
tab indentation. Instead, a where clause is typically used. To bind a single
|
|
name in a let clause, this is sometimes used:
|
|
|
|
foo = let x = 42
|
|
in x + (x-1) + x
|
|
|
|
-----
|
|
|
|
If you feel that this coding style leads to excessive amounts of horizontal
|
|
or vertical whitespace around your code, making it hard to fit enough of it
|
|
on the screen, consider finding a better abstraction, so the code that
|
|
does fit on the screen is easily understandable. ;)
|