Just to clarify, I'm not saying what I have right now is better than anything. I'm just prototyping various things that I think may be better, then try using them, and compare. When I get ideas how to improve it, I make the change and see. For what it's worth, most of the things I've tried ended up being bad ideas that I threw away, but in the process of trying them, I understood _why_ they were bad and what stopped them from being as awesome as I initially imagined.

> cmd1 | tee input2 | cmd2 | tee input3 | cmd3

Thanks for that tip, that's handy. However, it's still not quite good enough for me for the following reasons. You have to come up with a file name, and make sure it doesn't exist, or you'll overwrite a valuable file. Why should you have to come up with a file name when it's just some temporary output. Perhaps using a script that generates a temporary file name could help. But then you also have to cat that file to see its output. I don't see why the intermediate steps can't be visualized in an easier way, such as with a mouse hover or click. Also, what if you want to manually modify one of the intermediate values and see the effects? It can be done, but probably not in the most succinct way possible.

> GNU Plot

I was actually thinking that there might be something along those lines. I suppose there might be similar command-line tools that take png images via stdin and display them in a window. That's pretty close to what I'm trying to achieve. :)

> I don't know how to solve that off the top of my head, but I'm sure you could do it with a small tool.

This is still the most important ability to me. I'd like to be able to establish various "views" into the existing code base, that help me understand the things I want to know. Their main property is that they're completely generated from existing content, and have nothing user-generated that needs to be stored. When the source content changes, the views should update automatically (if possible). There's no reason they shouldn't unless you're trying to preserve battery life.

> Although I'm challenging some of your statements here, I do really admire your work on this.

Thanks, I appreciate your constructive criticism. :) I will use your feedback in trying to make this project more awesome.

> Also, I'd like to know what you mean by "make unnecessary duplication optional".

I should probably find a better way to phrase that, given how important to me that statement is.

Essentially, I want more things to follow the DRY principle [1]. I'm very annoyed when I fix a bug in a function, and then realize there are many more duplications of that code, so now I have to fix the exact same bug in many other places. I don't like like having to do the same work many times. But today's world is filled with such situations [2], and I want to my best to make it easier to reuse code rather than duplicate it.

Making something that I think is bad "optional" is just me trying to put a nicer spin on this. I would say "I want to eliminate all unnecessary duplication [of code/work/manual efforts]" but then what if someone wants to duplicate things on purpose for some reason? I don't have a problem with that. I just want to make it easier for you to not have to repeat work.

[1] http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

[2] Actually, I find that the situation has improved quite a bit in the last few years, and it seems to be improving slowly. But there are still many notable offenders that drive me mad and motivate me to work to make it a problem of the past.