“Hello world” in the BCPL language on the Xerox Alto simulator

I still have that experimental buffer opened, so I used the features for highlighting I described to highlight words "let", "buffer" and "create" with highlight-symbol-at-point, and the lines containing word "foo" with highlight-line-matching-regexp:

http://i.imgur.com/ubXumzK.png

The last four lines were generated by calling M-x hi-lock-write-interactive-patterns. If you save them in the file, Emacs can reload and reapply those highlights in the future.

I use it mostly when browsing log files, though the feature is useful for code too. Since I'm addicted to traditional syntax highlighting, I prefer the background change when highlighting code.

"A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader."

Yeah, I spent a few years thinking about a "wikipedia for code" which is almost exactly what you describe. But I eventually gave up on it for 2 reasons:

a) I started learning about the benefits of tests, and I noticed that this idea doesn't really have a good answer to how to make use of tests for reading.

b) I started noticing that in large teams and over time a good tool contains within it the seeds of its own demise. It's a little like creating roads to relieve traffic: for a while things are good, but then people start buying more cars (at least in the US), and eventually traffic is as bad as it used to be. In software, for example, high-level languages make it easier to declare function arguments (compared to say Basic's GOSUB), but now programmers start creating functions with 20 arguments, and that is as bad if not worse than GOSUB. Inheritance makes some kinds of control flow easier but also causes new kinds of spaghetti code. And so on and on..

These are the reasons why I stopped thinking in terms of just a tool. A tool helps existing habits, but loses control of new habits created around the tool. Changing practice, on the other hand, would affect both sides of the feedback loop. Instead of a vicious cycle of new abstractions (language features or tools) that hide details from the user and cause users to abuse them, I'd like to trigger a virtuous cycle where using a tool gradually makes you more likely to understand its internals. Lisp macros have that property: after using them for a few months I was surprised to find when I built a lisp interpreter how easy implementing macroexpansion was. It was as if macros were a (benign) virus that planted themselves in my brain as I used them. I'd like to create more such viruses :) It's a slower approach to changing things than creating a tool, it's true. But I think there's a lot more upside in the long run.