-
-
Notifications
You must be signed in to change notification settings - Fork 16
[#39] Move to Ansifmt #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad this is gone! 🚀
| (** A library for declarative UI definition. *) | ||
|
|
||
| (** Common styles for GitHub TUI. *) | ||
| module Style = Style |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm no longer exporting Style from both Pretty.Doc and Pretty.Layout. It was an unfortunate coincidence anyway.
Now Style should be used as Pretty.Style
| module Color = Ansifmt.Color | ||
| module Styling = Ansifmt.Styling | ||
|
|
||
| type t = Styling.t | ||
|
|
||
| let ( & ) = Styling.( & ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reexport things from Ansifmt to follow something kinda Domain-Driven Design and provide a small local wrapper around ansifmt so other modules inside GitHub TUI shouldn't depend on Ansifmt directly, only on relevant parts.
| let none = Styling.none | ||
|
|
||
| (* Repository name. *) | ||
| let repo = Styling.(bold & fg Color.blue) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to write just Styling.(bold & fg blue) without the Color but I don't really want to open Color.
Eh, fine for now, not a big deal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, perhaps we should re-export some of the common colors in Styling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I take it back. I'm doing the same Color.name in my website written in Elm:
I guess, words like yellow or magenta have the only implicit meaning of color. But for more exotic colors like "suva grey" or "gainsboro" it's not that clear that it's a color. So having a Color. prefix is better.
I'll keep the prefix everywhere for now for consistency. Usually consistency is superior to typing fewer characters occasionally.
So I wouldn't push for reexporting colors. In GitHub TUI, I'll probably introduce some specific colors locally for different themes, so it's not a problem at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I was a bit skeptical anyway
| let apply_background_hex_color ~hex text = | ||
| let color = Color.make_rgb_hex hex in | ||
| match color with | ||
| | None -> (text, `Light) | ||
| | Some color -> | ||
| let foreground_suggestion = Color.best_for_contrast ~threshold:80 color in | ||
| let contents = Printf.sprintf " %s " text in | ||
| let text = Styling.(wrap ~contents (bg color)) in | ||
| (text, foreground_suggestion) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function was so ugly and unsafe 😭
I'm glad it's now much prettier and saner!
| @@ -1 +1 @@ | |||
| let tests = List.flatten [ Test_color.tests ] | |||
| let tests = List.flatten [] | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was testing only my own Color implementation but now I don't have tests anymore, lol.
They'll be added later, don't worry. There're lots of tests to write.
|
@qexat This is mostly for you to review. Feel free to share your feedback or any comments 🙂 |
qexat
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. dune build @install builds fine locally.
Ansifmt 0.2.0 was just released, so we can pull it from the opam repository directly.
dc3d9a2 to
c63639d
Compare
|
I made Ansifmt pulling its source from the Opam repository instead of from source, as 0.2.0 was just released: https://opam.ocaml.org/packages/ansifmt/ (The force-push was due to an incorrect formatting of the commit message 😅 I thought it would handle |
Amazing! Thank you! 🙏🏻 |
heathhenley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
|
@heathhenley it seems that you don't have ansifmt installed in your current switch try running: opam install . --deps-only --with-test |
🤦- thanks all good now! Does anyone think we should throw a note in the readme about how to update switch when deps change / update? I was also thinking about the list of 'non-obvious' things you mentioned in the other thread - wonder if using the log module to log debug info to a file would count (for dev)? And getting / setting your github token (for everyone) |
I don't mind the idea for having tips for developers. Currently, we have a section in README for that. So feel free to add more to it, like updating a dependency or using logs 🙂 We don't have lots of docs yet, so it's fine to write everything in README for now. In the future, we'll probably have a separate |
|
Thanks @qexat and @heathhenley for the review! Merging 🙂 |

Closes #39
It was surprisingly easy to migrate! I haven't noticed any regressions in the behaviour. Label background and foreground based on luminance still work as expected:
I'm glad that quite a lot of bespoke logic got deleted, and there's a smaller context to keep in mind while working on this project.
Have a look and let me know if it makes sense!