kindaro/cabal-prettify

cabal-prettify's Issues

Add a regression test for the backing up and overwriting logic.

As said in the overview of the package:

1. Prettified files are backed up with the extension *.previous.

   1. Files that are already pretty are not backed up.

      This ensures that running cabal-prettify twice in a row does not overwrite the original.

This is hazardous. I should add a regression test.

Where are my comments?

At this time, cabal-prettify erases all comments. Ideally we should like to keep them.

Hate mail box.

Leave your vile deconstruction of my honest work here, so that I know what issue not to read.

You can also say something nice if you feel like it.

Awareness of Cabal projects?

We have the option this that tells cabal-prettify to prettify the cabal file nearby — do the right thing.

• At this time, we call "Cabal" Distribution.Simple.Utils.defaultPackageDesc. It looks for the nearest Cabal file.
• Ideally we should be aware of Cabal projects and prettify all the cabal files in a project, but this will take some work, because the code that works with Cabal projects is buried inside the cabal-install:exe:cabal executable.

Type set all keys in lower case.

All of these are valid in the eyes of Cabal:

• build-depends
• Build-depends
• Build-Depends

In my eyes, only the former. We are not yet at a stage where importing beautiful capitalization from natural languages makes sense. Best we can do is type set all keys in the lower case.

New line after a long list?

We unfold long lists into multiple lines. But in big projects there can be lists of hundreds of lines. It makes sense to insert a new line after such long lists to make navigation easier.

List of characters, array of bytes?

At this time, we are wielding Cabal's parser. It is a weird thing: taking ByteString as input, but working in String terms. We end up jumping back and forth between these two types. The perfect solution is to work with Text — the type of arrays of characters.

• The underlying parser — parsec — treats ByteString as a stream of characters. This is not ideal.

  However, parsec also supports Text and this is what we need. It should be easy to rewrite Cabal's parser to work with Text.

• The underlying printer — pretty — has String hard wired into it. This is not ideal.

  Maybe we can generalize it to IsString, since it is in base since forever?

Were these dependencies appropriately generalized, Cabal's parser could be patched to wield Text on the cheap.

I am unwilling to talk to the maintainers of the packages above — my expectation is that they will not be forthcoming. The local maximum is to patch the dependencies myself and depend on forks.

Check if formatted, but do not format?

For the purpose of continuous integration, it would be good to have an easy way to check if cabal files are formatted. To this end, we may compare the input with the formatted input and exit with an error if there is any difference.

This is easy to do by itself, but there is hardship is the designing of the human interaction. A command line flag needs to be added. How should it work when the target is standard input? Should it still print the contents? Kind of yes (we want the program to be a filter when the target is the standard input) and kind of no (this mode is not supposed to do anything other than exiting with either success or error).