I happy to hear that it worked for you and that it worked on Windows. I don't own a Windows, so I have not tested it. I am pleasantly surprised that it worked as I have not tried it out on Windows. I will try to improve the speed with next future versions and will try it out on Windows as well as will try WizTree to get to know it. Thank you

I did not want to expose what is inside my disk, so I did not share an example but I can do it :D This tool does not let you delete by itself but shows you the size and the path, which you can copy and then remove via terminal

I discovered ncdu after I created this tool and it is neat and very well developed. However, this tools serves a bit different purpose, it focuses on the biggest files in categories, so that I could find what to possibly remove in order to free up space (or move to another place)

That is coming soon!

Thank you for the feedback and for the link. This is something I also do for SQL code. Initially I was making this to be used as a pre-commit hook for SQL code inside Python for our team. Probably inspired by the black Python formatter. I just made the MVP and will propose to our team to use it after the holidays. If regexes would seem to be not enough, we still have the power of Python to lend a hand for more complex puzzles

Thanks, that's definitely coming in the near future

Thank you for the feedback. The example in Github has code highlighting. I wonder if I should remove that and if that would make more difference. I would be interested to know how this tool could help you with your SQL usage

Every IDE I use and have used for the last 15 years has included an option to format the code the way someone else believes it to be best viewed. I have never found these to be the way I prefer SQL to be formatted for the best readability.

A difficult but incredibly useful idea would be to learn the developer’s style and then format code (theirs or others’) to fit that model.

Thank you for the feedback, it will be useful. This is something I had in mind and I believe this would be even more powerful but I started with this minimalistic approach. It might grow into something like this later

I understand the wonder, this is not some kind of magic that will help us solve all SQL issues. That's way too hard. This is a development tool that helps write and read SQL code. So simply saves development time by automating the easy stuff, leaving the hard and important stuff for us to deal with. It is different from other formatters that it lints code inside Python strings. For some context, I am a data engineer and I write a lot of SQL code inside Python code (in the future it should support other programming languages as well).

However, the tool might suggest improvements on SQL code in the future

Ok that puts it in context a little bit, if it’s making your life easier then it must be useful to people in the same position and role. I’ve o it ever written SQL in stored procs and one off queries so relied on Redgates SQL Prompt tool (you might want to take a look at what that does for some inspiration)

Thank you, I can definitely look up for some inspiration from Redgates. I see that it also costs some money

For now it only upper-cases but I would like it to "prettify" the code as well. So it is an upcoming feature. Hopefully it will even suggest SQL code improvements in the future. Contributions are welcome

I don't really get it. Is upper case more human readable than lower case?

Me neither, when copying uppercase sql i always lowercase everything. But I can understand that some people are more used to that format even though I find it obsolete.

In any case, it is objectively not more human writeable.

Not for everybody probably but I find it more readable, especially when the queries get big. Some people rely on code highlighting but this usually gets messed up when writing SQL code inside Python strings

By distinguishing key words from table names and column names, uppercasing can improve readability, since SQL has such a flexible/variable grammar.

If we wrote:

    select(col1, col2, col3, ..., from=table_name, limit=5)

or something like that, it's obvious what are the intrinsics and what are the variable parts without knowing anything about select but for SQL you need to know all the "sentence patterns".

It’s actually been proved to be the opposite... which is probably why a lot of legalese you aren’t meant to read but they’re required to provide is written in small print upper case.

This has to do with the outline of letters in uppercase being indistinct (if you trace an outline - especially with serif fonts - you’ll largely just get a block) so you need to spend more time per-letter to distinguish the characters whereas with lowercase, the “fitted box” shape is shared between fewer letters: https://www.sciencedirect.com/science/article/pii/S004269890...

I am not claiming that upper-case is more readable in general. I know the practice to write SQL keywords in upper-case and I find it more readable. From https://stackoverflow.com/a/608201/7714279 "You can easily separate the keywords from table and column names, etc." However, it's a choice. Some people rely for code highlighting but this gets messy if we write SQL code inside Python code. This is especially where this library comes to lend a hand

While I agree that uppercase is hard to read, turns out there is a good reason for caps in legal docs:

"Under US law, disclaimers must be 'conspicuous'" https://law.stackexchange.com/a/18210