vlasovskikh / xdu Goto Github PK

Hi,

I'm a thankfully long-time user of xdu, recommending it to many peers as an easy to use visualization tool for disk usage.

A Little Background Story

As a user of Emacs Org mode (in short: "Org"; here, it doesn't matter if you know it or not) I once had a glorious idea. Org is (among many other things) a note-taking and note-managing tool. My knowledge-base is within Org files. One fine day, I had the urge to visualize the number of lines that corresponds to different hierarchy entries of my knowledge-base. "Just like xdu is doing it for directory sizes" was one of my first thoughts.

I'm not a good programmer myself and I've got almost no experience with GUI programming. Therefore, I had a bit of a problem.

Suddenly, an idea struck my mind which was a very elegant solution to my problem: why not mimic the simple output of du and generate such a du-result file from my Org mode file, using xdu to visualize the content accordingly?

I still do think that this idea was a great one. Analyzing the du output format is trivial, parsing Org files and generating a similar output format with number of lines per heading instead of disk usage per directory was a piece of cake.

The result can be seen and downloaded from https://github.com/novoid/org-du and it even got fourteen stars! ;-)

One Step Further

So we do have the output of du which then gets fed to xdu for a nice interactive visualization.
I used a creative trick to misuse xdu to visualize heading "weights" of Org mode files by generating a du-like output file.

Now here comes the logical next step: What about extending the goals of xdu and embrace it as a generic interactive visualization tool for all kind of formats?

Want to visualize Org mode headings by number of lines? Try xdu < my_file.org
Want to see the structure of a JSON file? Try xdu < my_file.json
Need more insight on an XML file? Try xdu < my_file.xml
Many other examples are to be explored.

I know, this is a huge step to make, considering the narrow focus of xdu so far, its name choice as well as the number of things to solve for a realization:

• Is it necessary to define the input format per command line argument?
• How to define the set of supported input formats?
• Should there be some kind of modular design so that people might add input format modules themselves without changing xdu?
• Would it be a better idea to define a more flexible input file format to enable more features like "jumping to a specific part within the source file", invoking external commands for different purposes, ...?

All these questions can get their answers when a few talented people are joining the party. Since I can't code in C, I can contribute on the conceptual level as well as with documentation and testing.

I'd love to see xdu becoming a generic visualization tool, following one of the UNIX principles as summarized by Peter H. Salus in "A Quarter-Century of Unix":

• Write programs that do one thing and do it well. -> proportional visualization of data + navigation within
• Write programs to work together. -> not limited to the output of du only
• Write programs to handle text streams, because that is a universal interface. -> not limited to the output of du only