What outliners should be able to do (on inherent features and interoparability)

Posted by Fredy
Aug 12, 2012 at 10:13 AM

Preliminaries

As we all know, the Kant professor advocated two things before leaving: ConnectedText (CT) and AutoHotkey (AHK). The irony is, many use CT know whilst there’s no further mentioning of AHK.

In 2011, I was on a commercial macro tool, with all its limitations. In 2012, I’m on AHK now, and the possibilities are tenfold, but there are limits, and those helped me to see clear on the “What an outliner should be able to do at the very least” subject.

When I’m speaking of outliners, I’m speaking of the 2- and 3-pane variety only (I’m not interested in the notion that “only 1-pane outliners are real outliners - that might be true, but then donate us with a term for the 2/3-pane things, and I’ll never speak of outliners anymore).

I said, we had paper stacks (with sort sheets / slips, and also with tiny “favorite” slips (clipped or glued, what do you call them) 30 years ago, and from many outliners today, 30 years later, we basically get electronic search on top of that, nothing more, whilst alternative views on your material - a thing that was possible with paper but only if you didn’t sleep anymore or had two or more secretaries - would be a strict minimum, given the easiness for a computer to do so AND the extreme usefulness of this for anybody using such sw. And I said, in the ActionOutline review on cnet, that a non-fleeing search results table was the strictest minimum to such an alternative view (while there are others, better ones, and best would be to have several of such alternative views concurrently).

Bill (MadAboutDana), I agree with you that there might be other “basic” features an outliner might have.

One day in 2011 (= I on my macro tool, not on AHK yet), in the UltraRecall forum, I asked for SEVERAL text expanding resolve files (UR has got, from its MS editor like other MS products, text expanding, but only from one such file, i.e. you don’t have alternative vocabularies at your disposal, for several languages, for several subject contexts, etc. - just one for all) - no answer, and I even wrote a macro that would have exchanged that only resolve file by others, but you had to close down and reopen UR in order for that, so it was a dead-end.

Tranglos in the donationcoder forum said, on editors, he uses several ones of them, concurrently (like me), and thus he doesn’t use any in-built language-specific expanding features, etc. within those editors, but he uses AHK for text expanding instead, since that allows to script the text expansion, etc. once, and then use it in any such editor he might use at any time - btw it goes without saying that AHK allows for “general scope” (application) AND for “deep scope” (the “control” having focus in any such application) AND for multiple such “expansion tables” - the possibilities are almost endless, from that.

Combine my unfulfilled wish in the UR forum with Tranglos’ using his overlayed script language on several applications, and you’ll get two things:

- Perhaps the usual outliners’ approach “one thing does it all” is a fault-in-thinking from start on (and indeed it is, I developed this during the last months in the UR forum).

- Clearly distinguish between what an application NEEDS TO DO ITSELF, and what it SHOULD ALLOW to do, by external means.