-
Notifications
You must be signed in to change notification settings - Fork 11
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
Pretty indendation and coloring should be separate options #15
Comments
So maybe don't force Since this repo is in Hacktoberfest I could be interested in doing a PR on this. |
Thanks for the suggestion! I think let's start with with shorthands off = happy for a PR on this @Macroz |
implemented in the latest release - thanks @Macroz https://github.com/markus-wa/cq/releases/tag/2022.10.12-14.51.05 |
pretty was released with automatic logic for enabling colors. Seems pretty straightforward: clj-commons/pretty@7cb0c16 |
So I implemented #18 as described, but I'm not sure this logic (from The code detects if you are in a TTY alright, but if you don't pipe to a file but to your terminal (e.g., for one-off manual use and exploration), you probably want to see the colors. You are likely also not in a REPL. So this kind of detection would mean the default is uncolored, and you must force the colors with a flag pretty much always. Any more ideas? |
Thanks @Macroz - I think that's as good as it gets. As far as I'm aware there is no way to differentiate between pipe to command vs pipe to file (also, commands like It's preferrable to break colouring vs breaking pipe to file. Would you be able to open a PR? 😄 |
Right! How about this for a PR #20? |
Currently the only options are to either indent and colorize, or not do either. Colors make it difficult to work with files, or really anything that cannot handle the terminal/ANSI color codes. Would be nice to have command line options to have the pretty indentation without colors.
Or perhaps logic that can see if stdout is attached to a TTY, but looks like that can get pretty hairy in JVM. I guess even more so with graalvm.
The text was updated successfully, but these errors were encountered: