Skip to content
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

Feature request: Include padding for sign for columns with positive and negative numbers #80

Open
Heeten opened this issue May 4, 2024 · 2 comments

Comments

@Heeten
Copy link

Heeten commented May 4, 2024

I love csvlens, this has been a super helpful tool for my work. I am wondering what you think about this feature request. If I have the following table:

date         a           b 
2019-01-02   -0.002426   -0.002555
2019-01-03   -0.008189   -0.008318
2019-01-04   -0.001163   -0.001294
2019-01-07   0.005784    0.005654
2019-01-08   0.004757    0.004627
2019-01-09   0.000067    -0.000062
2019-01-10   0.000059    -0.000070
2019-01-11   -0.001242   -0.001371
2019-01-14   0.002140    0.002010

I would like if the columns without - had an extra space so it rendered aligned.

@YS-L
Copy link
Owner

YS-L commented May 5, 2024

Thanks for the suggestion!

One principle I would like csvlens to follow in general is to not interpret the content of the csv beyond parsing out the fields, and to render the content faithfully. Adding extra spaces requires recognizing a column as numeric with a certain formatting and also modifies the original content, which kind of goes against that principle.

So for now I think it's unlikely that I will prioritize this, but I'm also curious what other users think about this.

@pataquets
Copy link

pataquets commented Oct 8, 2024

Although the OP FR is very desirable, I agree with @YS-L's stance on this and I also think such principle should prevail here.
The only "no exceptions/specific code" alternate approach I can see this being achievable is under some sort of printf-style generic column formatting feature, which would cover also this case for numbers.
Needless to say, this feature should fail gracefully if the column type could not be determined (ideally, the formatter would be responsible of guessing the type), so no nasty side effects if the user chooses an incorrect format and no extra type-guessing code would overflow outside the formatting feature.
Just my 2c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants