tomos, it will - but that' not the prob.

SOME people here mix up "keywords" / additional tags within an otherwise hierarchical data repository, and a tagging system (treed or not, and where such a contextual data hierarchy simply is not there) - these are two different worlds, conceptually. All about trees and tags in the outlinersoftware forum (whilst my very first musings about the difference in paradigm was here, in a discussion with Paul, some year ago).

So some current Surfulater users might be in for a shock if they really try to switch to NextGen (and if Neville does away with the non-tag tree indeed). For the casual reader who's not willing to delve into details: Just consider that today's tagging systems do not allow for "manual sort" of the items to be found in some tag tree subtree, whilst in outliners you do manually sort siblings in order to give them more "meaning", more "accessability", in a word/term, "natural order for current context", and of course, for some 20 or 30 such siblings, and for serious / efficient work, that's an important criterion for your data repository.

And yes, for SOME, very specific data collections, tags are best (here again, details in outlinersoftware.com).

But tag trees try to overcome the above-mentioned endless-keywords-lists probs, but try to apply the tagging concept to stuff that had better be put into a tree, with clones. Here again, for the casual reader: Tags are best for traditional db items, i.e. stuff that sometimes is considered in "collections", to compare, but which is treated "one-by-one"; whilst "tree stuff" is data that has to be "combined" to be useful, be it combinations of items(' partial content) in order to create additional items, or be it "just" for your "consideration", and your decision-making: Here, as I have developed illic, the "manually sorted context" of the tree concept (whilst subject to necessary amendmend, I perfectly acknowledge that (keyword here: in current realizations, no variants in sorting for different contexts, let alone subgroups / easy combination variants)) should be preferred.

Current RightNote neither has clones, nor has it viable tag M, so it's not good for anything, considering its bug make it doesn't even have working Boolean search. But there certainly will be a version 4, much better than the current one.

IM is about making available anything possibly relevant info in an optimized way, and without the (academic or corporate) user going crazy in the process, i.e. complexity reduction, yes, but not to the point of leaving relevant things out; and in tagging systems for academic stuff, it's the poverty of the tool that then triggers unnecessary manual, additional work "on arrival" - dont mix up neatness and primitiveness. Join me illac, and let's see if we can find some improvement of either concept together.

VERY IMPORTANT ADDITION

The tutorial above mentions the "autoexec section" two times, but it's very important to clearly identify that section, in order to not run into probs since AHK "allows" for very sloppy programming/scripting, i.e. it doesn't notify that when loading the script, but you'll have to work it out afterwards, often without knowing where the error might lie.

So, first you'll have the auto execute section (aes) "à proprement parler", i.e. the one you THINK is the aes.

Then you do the menus (if you have any), which also belong to the aes. (Here, it's very important to list the sub-menus BEFORE the respective parent menus, in order for AHK to "find" them. This is worth mentioning since logic and "script beauty" would ask otherwise.)

Menu example:

Menu, File Managers, add, &SC 25, speedcommander25
Menu, File Managers, add, &TC, totalcommander
; and so on

This is then the real end of the aes (or that is what you think).

Then you do the labels, example:

speedcommander25:
   run, "C:\Programme\SpeedProject\SpeedCommander 25\SpeedCommander.exe"
   return

So this is the very first element of the "persistent" (= continuously running) part of your script
( see above:
; #Persistent : not necessary here since this script is persistent anyway because it contains hotkey assignments
) - or so you think.

Similar with key assignment and such, as for example

a:: send, Some Text to appear in the currently active applic

Now, the AHK help http://www.autohotkey.com/docs/Scripts.htm says,

"The Top of the Script (the Auto-execute Section)
After the script has been loaded, it begins executing at the top line, continuing until a Return, Exit, hotkey/hotstring label, or the physical end of the script is encountered (whichever comes first). This top portion of the script is referred to as the auto-execute section."

Now, with VERY careful reading, you could indeed deduct from this that the above label is NOT included in what the help file says here, but it's exactly such "you must read it oh so carefully up to the finest details" AHK "help" file style that makes the fortune of paid macro tool developers; I did never grasp that detail in two years of AHK with thousands of lines in my scripts, and it wasn't at the moment that very first program was NOT loaded automatically anymore from the little and highly recommendable tool

"Startup Control Panel 2.8 by Mike Lin"

that I became aware of my having done something wrong, since any (first or re-) loading of my main AHK script loaded that very program, again and again, anyway. I then "out-commented" that very first label, and now, the second label was executed for every script loading, and here I grasped my error...

I have to say that I had put all my key assignments BELOW my labels; if I had it done the other way round, the problem would not have arisen.

Now, you will do this, in order to avoid any such fuss:

- Have your "real" autoexecute section

- Then, have your possible menus (which you want to be available anytime)

- Then, in any case (with menus or not before), insert these lines into your script:


; End of autoexec section (return) (or any other comment to remind you)
return


- then, do labels, key assignments, etc., etc., in every which order you want

Some very important details ain't obvious in AHK; it's important to list them in any intro. Sorry for sharing this one so late.