kowainik / colourista Goto Github PK

even though there are no build errors caused by the library itself

We have human-readable aliases for IO printing functions. Currently they are just aliases to corresponding functions blueMessage, yellowMessage, etc. But I thought that maybe they can append some indicator to hint their meaning. Currently I can think only of the following unicode symbols:

• successMessage: ✓
• infoMessage: ⓘ

We also have:

• skipMessage
• warningMessage
• errorMessage

So when you info infoMessage "Some information", you will have

 ⓘ Some information

What do you think? We need to decide on symbols for other functions as well...

Formatting with bold and italic has no effect when running in powershell/cmd on Windows (win10, winver=1809). Most probably, this is a limitation of the underlying ansi-terminal, not colourista, but I wanted to make this known nevertheless.

Example (colourista-0.0.0.0, lts-15.0, ghc-8.8.2):

{-# LANGUAGE OverloadedStrings #-}
module Main where

import Colourista

main :: IO ()
main = do
    putStrLn $ formatWith [bold, red, cyanBg] "Кириллица bold red cyanBg"
    putStrLn $ formatWith [bold, red, cyanBg] "Latin bold red cyanBg"
    putStrLn $ formatWith [bold, italic, red, cyanBg] "Latin bold italic red cyanBg"
    putStrLn $ formatWith [] "Latin"
    successMessage "Done"

yields in my powershell (with required unicode-enabling settings, of course)

Cmd (with chcp 65001) behaves similarly.

https://hackage.haskell.org/package/ansi-terminal-0.10.3/docs/System-Console-ANSI-Types.html#t:Underlining

Not sure, as a separate test suite or with doctest, but it would be nice to have some simple automatic tests E.g.:

• Verify that yellow adds proper code by default
• Verify that formatWith works

And remove Travis and AppVeyor.

As I saw currently user can only select colours mentioned in this data type.

https://github.com/feuerbach/ansi-terminal/blob/5d65f48485182320ea05f90b5b002003515c089b/src/System/Console/ANSI/Types.hs#L39-L47

There shouldn't be too difficult to add additional function and maybe data type to wrap Colour from colour package so that user can write a message with any foreground or background colour (thanks to the this line). That would require to add colour package in the dependency list and to add some additional function available for users. If you think that this is a good idea, I can start working on this.
🎄 🎅 🎁

Often enough we write code like

myFormat s = red <> bold <> s <> reset

I think we should have a function like this:

formatWith :: [String] -> (String/Text) -> (String/Text)

So it can be called like this:

formatWith [red, bold] myText

• Common stanzas
• Delete redundant stack.yamls
• Use GHC-8.8.2

Different functions to work with prompt.

Example functions:
https://github.com/kowainik/summoner/blob/60de4f2f087e5bd2beaad9253e7eded731cfbaaf/summoner-cli/src/Summoner/Question.hs

commercialhaskell/stackage#5592

Specifically, colourista-0.1.0.1 can be expanded to base < 4.19.

To specify indentation:

indent :: IsString str => Int -> str

I find myself writing

b :: Text -> Text
b = formatWith [bold]

i :: Text -> Text
i = formatWith [italic]

again and again.

I propose to add a module in colourista with such functions for faster small styling.

What do you think @chshersh ?

It would be nice if colourista could support automatic disabling and enabling of colouring, so we can easily disable/enable colours in our code. We want to have a solution that satisfies the following requirements:

1. Allows specifying the colour only in a single place in the application.
2. Colours the text by default, if no option is specified.
3. Doesn't involve code duplication.
4. Doesn't require code recompilation to change colouring settings.

I'll describe one possible solution below.

-XImplicitParams

One way to do this is to use the ImplicitParams Haskell language extension. It contains the following parts:

1. Implement simple enum to control colouring mode.

   data ColourMode = EnableColour | DisableColour

2. Introduce a constraint with implicit params:

   type HasColourMode = (?colourMode :: ColourMode)

3. Patch each function to pattern-math on a colour:

   withColourMode :: (HasColourMode, IsString  str) => str -> str
   withColourMode = case ?colourMode of
       EnableColour -> str
       DisableColour -> ""
   
   red :: (HasColourMode, IsString str) => str
   red = withColourMode $ fromString $ setSGRCode [SetColor Foreground Vivid Red]
   {-# SPECIALIZE red :: HasColourMode => String     #-}
   {-# SPECIALIZE red :: HasColourMode => Text       #-}
   {-# SPECIALIZE red :: HasColourMode => ByteString #-}

4. Implement magic instance described in this blog post to make EnableColour default:

   -- ?color = EnableColor
   instance IP "colourMode" ColourMode where
       ip = EnableColour

Cons and pros

Implementation cost: patch each function.

Pros:

1. All existing code should work without any changes.
2. We can easily disable/enable colouring by defining a single variable in a single module after we parse --no-colour option or something like this.

Cons

1. Each function that performs colouring or calls colouring function should add HasColourMode constraint.
2. You don't have compile-time guarantees if you forget to add such constraint somewhere.
3. This involves using non-common GHC feature.

Additionally we need to add tests for this:

• Check that disabling colour mode actually disables colour codes

Of course, only if it's possible.

See this comment: #9 (comment)