Just like other pragmas annotations will now “stick” to the definitions they
pertain to. If it's not possible, there will be a newline separating them
from other declarations in the module.
Most syntactic constructs reuse pretty printing specified previously, such as arrow cases, if-expressions and lambdas. Relevant operators (such as arrow argument passing) and brackets are also formatted as operators and brackets typically are.
Certain other kinds of declarations, such as instance signatures (e.g., from `InstanceSigs`) and bindings, are grouped together without newlines. The process for determining which declarations are grouped reuses the same logic as for modules and type classes.
Certain other kinds of declarations (such as associated type signatures and
bindings) are grouped together without newlines. The process for determining
which declarations are grouped reuses the same logic as for modules.
* Point to more recent nixpkgs commit. This fixes build issue with python
3.7.3 (only on darwin?).
* Separate shell.nix and default.nix. This is so that lorri can be used for
development.
* Add nix output to .gitignore.
* Format *.nix using nixfmt.
* Use gitignore for filtering files in nix derivation.
There are no real problems to speak of, as the formatting is obvious and consistent with what the Haskell community already does.See the tests for an example.
The reason transform list comprehensions are not implemented yet is because the GHC AST for representing list comprehensions is ahorrible mess, where slightly different list comprehensions end upcausing massively different syntax trees. The simplest way of solving this would likely be a preprocessing step that reads the syntaxtrees and produces a simple, linear list of bindings. I decided not to implement this yet to avoid delaying this commit further.
The PR changes the body layouting to use a span that includes the last point in
the name/pattern part of a match. This forces the layout to be multiline iff the
body starts on a newline.
I'm not sure it's perfect, but it fixes the original issue and all the tests
pass.
The problem was in entering with locate (or some version of it) the same
span twice. So the algorithm saw an element with identical enclosing element
and the ‘commentFollowsElt’ function got confused.
The solution is two first augment registration of enclosing spans to allow
us to keep more than one item there. Then we can filter out spans which are
just copies of current reference span to get to the “real” enclosing span.
It seems to make sense to attach comments to child element if it starts
exactly at the same position of parent element, hence the distance between
start of enclosing/reference span and start of comment is the same, thus
changing ‘>’ to ‘>=’ in ‘commentFollowsElt’.
