Yes. I also prefer the latter, it's more diff friendly and has more consistent indentation. We should pick and indentation amount (2 or 4) and stick with it. I vote for 2, just because that's what I use. :) If we could encode a style guide in a formatter, it would be much easier for us to do automatic rewriting of Cabal files, which is needed for features like `cabal freeze` P.S. I think Duncan wants to do this as well, but he got stuck on some Parsec dependency like issue IIRC. On Wed, Feb 26, 2014 at 2:48 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

I don't see why not.

On Wednesday, February 26, 2014, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:

...

Hi all,

the current cabal file pretty printer creates output in the form:

... extra-source-files: README.md tests/inputFiles/original.cabal tests/inputFiles/setup-config tests/goldenFiles/*.cabal tests/outputFiles/.gitignore

library build-depends: base >=3 && <5, cmdargs >=0.10.5 && <0.11, lens >=4.0.1 && <4.1, strict >=0.3.2 && <0.4, Cabal

...

=1.18.0 && <1.19 exposed-modules: CabalBounds.Args CabalBounds.Main ... other-modules: Paths_cabal_bounds CabalBounds.Bound CabalBounds.Targets CabalBounds.Dependencies CabalBounds.Drop CabalBounds.Update CabalBounds.Lenses ...

Would a patch be accepted that creates output that is more diff friendly?

Something like:

extra-source-files: README.md tests/inputFiles/original.cabal tests/inputFiles/setup-config

library build-depends: base >=3 && <5, cmdargs >=0.10.5 && <0.11, lens >=4.0.1 && <4.1, exposed-modules: CabalBounds.Args CabalBounds.Main ... other-modules: Paths_cabal_bounds CabalBounds.Bound CabalBounds.Targets ...

Or perhaps:

extra-source-files: README.md tests/inputFiles/original.cabal tests/inputFiles/setup-config

library build-depends: base >=3 && <5, cmdargs >=0.10.5 && <0.11, lens >=4.0.1 && <4.1, exposed-modules: CabalBounds.Args CabalBounds.Main ... other-modules: Paths_cabal_bounds CabalBounds.Bound CabalBounds.Targets ...

I think that I might prefer the second one.

Greetings, Daniel _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

On Wed, Feb 26, 2014 at 3:51 PM, Tillmann Rendel < rendel@informatik.uni-marburg.de> wrote:

1. change `cabal init` to use the pretty printer. 2. expose the pretty printer at the command line.

Agreed on both points. We should add (2) as `cabal format` (similar to go-fmt) or something like that.

On Wed, Feb 26, 2014 at 4:01 PM, Johan Tibell wrote:

On Wed, Feb 26, 2014 at 3:51 PM, Tillmann Rendel wrote:

...

1. change `cabal init` to use the pretty printer. 2. expose the pretty printer at the command line.

Agreed on both points. We should add (2) as `cabal format` (similar to go-fmt) or something like that.

I would love to have this, it would make editing cabal files with tools much more appealing. What would be ideal would be a way to edit the files while preserving whitespace. But I know from haskell-src-exts that this is a very tricky thing to get right. Regards, Erik

On 2014-02-27 at 20:23:59 +0100, Erik Hesselink wrote:

On Wed, Feb 26, 2014 at 4:01 PM, Johan Tibell wrote:

...

On Wed, Feb 26, 2014 at 3:51 PM, Tillmann Rendel wrote:

...

1. change `cabal init` to use the pretty printer. 2. expose the pretty printer at the command line.

Agreed on both points. We should add (2) as `cabal format` (similar to go-fmt) or something like that.

I would love to have this, it would make editing cabal files with tools much more appealing. [...]

...not only that, it might help for extracting information from .cabal files via shell script commands (like .e.g. package name, package version so on), if they can be normalized to a simpler to parse canonically indented format (without having to write a tool in Haskell using the Cabal parser directly...)

On Sat, Mar 01, 2014 at 01:58:14PM +0100, Daniel Trstenjak wrote:

is there a reason why the function 'fieldGet' of 'FieldDescr' in 'Distribution.ParseUtils' formats only the contents of the field and not also the field name?

Having the field 'build-type: Simple', then 'fieldGet' only formats the part 'Simple' and the 'build-type: ' part is formated in 'Distribution.PackageDescription.PrettyPrint'.

This makes it harder to give certain fields a nesting without special casing in 'Distribution.PackageDescription.PrettyPrint'.

If the complete field would be formated by 'fieldGet', then nesting could be nicely integrated into the 'listField' and 'commaListField' functions of 'Distribution.ParseUtils'.

I have now created a pull request for this change on github. Is github the right place for doing this for cabal? Greetings, Daniel