cabal-gild-1.5.0.1: Formats package descriptions.
Safe HaskellSafe-Inferred
LanguageHaskell2010

CabalGild.Unstable.Action.FormatFields

Synopsis

Documentation

run :: Applicative m => CabalSpecVersion -> ([Field (p, [c])], [c]) -> m ([Field (p, [c])], [c]) Source #

A wrapper around field to allow this to be composed with other actions.

field :: CabalSpecVersion -> Field (p, [c]) -> Field (p, [c]) Source #

Formats the given field, if applicable. Otherwise returns the field as is. If the field is a section, the fields within the section will be recursively formatted.

isConditional :: CabalSpecVersion -> Name p -> Bool Source #

Returns True if the field name is a conditional. if is always one, and elif is one for Cabal versions 2.2 and later.

fieldLines :: CabalSpecVersion -> p -> [FieldLine (p, [c])] -> SomeParsecParser -> [FieldLine (p, [c])] Source #

Attempts to parse the given field lines using the given parser. If parsing fails, the field lines will be returned as is. Comments within the field lines will be preserved but "float" up to the top.

floatComments :: p -> [FieldLine (p, [c])] -> [FieldLine (p, [c])] Source #

Collects comments from the given field lines (see collectComments) and attaches them all to the first one.

collectComments :: [FieldLine (p, [c])] -> [c] Source #

Collects all comments from the given field lines. Their relative order will be maintained.

style :: Style Source #

This style attempts to force everything to be on its own line.

parsers :: Map FieldName SomeParsecParser Source #

A map from field names to parsers. This determines which parser should be used for which field. And consequently this determines which fields will be formatted.

Perhaps instead of being keyed on FieldName, this should be keyed on a path (list of field names) instead. That's because a field like build-depends only really makes sense within a section like library. Fortunately field names are unique enough that this hasn't been a problem yet.