Closed braffes closed 1 year ago
Yes, I also think the current usage causes problems, but it may be jarring to see color on a test set but nothing when there are more than 20 entries.
Can you set the less default: export LESS="-R"
and check if click picks up that it can display color? If it does not, we can recommend aliasing reportseff as reportseff --color
. But what happens if you run reportseff --color --no-color
, e.g. running the alias with no color?
export LESS="-R"
reportseff --partition common --user=braffest --since w=2 |less --> no color
reportseff --partition common --user=braffest --since w=2 --color |less --> color
reportseff --partition common --user=braffest --since w=2 --no-color --color --> no color (with and without pipe less)
reportseff --partition common --user=braffest --since w=2 --color --no-color --> color (with and without pipe less)
I don't understand why do you want to use less here. I also don't understand why do you want to use an alias.
reportseff --since d=7 will output in color on my shell without need of pipe.
It will use a new pager ( as you have wrote in your current code).
The default behavior will display a new pager with colors, and without needing of less. So in my opinion, we don't need piping anymore and don't need to alias reportseff.
Interesting, I remember without forcing color the pager wouldn't have color, which is why I overwrote the default in the first place. I was assuming your reportseff example was fewer than 20 lines. Let's make the change.
Do you want to work on a PR or should I? The README and unit tests may need some work as well.
Yeah, my output was for more than 20 lines.
I will try to do it in the next days.
Hi,
I am wondering if it is possible to change the behavior of the option color/no-color. By default, with more than 20 lines, it will create a pager with the color activated because the default of color is True:
I think it will be easier to use reportseff for an user, if it let the default value of color of the function echo_via_pager which is "autodetection".
So the library will detect if it can display the color or not.
In my example, I modify a bit the function main by the following code :
Where args.color is equal to None (instead of True) if the option is not set.
So with this "solution" : -->
reportseff --since d=7
will output in color on my shell without need of pipe. -->reportseff --since d=7 >output_reportseff
will write in the file without color. -->reportseff --color --since d=7
will output ANSI color codes on my shell, need to pipe with less -R to be readable. -->reportseff --color --since d=7 >output_reportseff
will write in the file the ANSI color codes need to use the option -r to be readable. -->reportseff --no-color --since d=7
will output without color on my shell. -->reportseff --no-color --since d=7 >output_reportseff
will write in the file without the color.The current behavior : -->
reportseff --since d=7
will output ANSI color codes on my shell, need to pipe with less -R to be readable. -->reportseff --since d=7 >output_reportseff
will write in the file the ANSI color codes, need to use the option -r to be readable. -->reportseff --color --since d=7
will output ANSI color codes on my shell, need to pipe with less -R to be readable. -->reportseff --color --since d=7 >output_reportseff
will write in the file the ANSI color codes, need to use the option -r to be readable. -->reportseff --no-color --since d=7
will output without color on my shell. -->reportseff --no-color --since d=7 >output_reportseff
will write in the file without the color.So it will only change de default behavior, if you don't set the option color/no-color.
I have seen what you have write here https://github.com/troycomi/reportseff#my-output-is-garbled-with-esc0m-all-over-wheres-the-color, but it seems to me more user friendly with my approach. What do you think about that?
I hope it is understandable, thanks for your tool again !