Unfortunately, I think Vista's safeguards (described earlier) make it impractical to store custom/user functions in A_AhkPath. In addition, it would feel less professional because these custom functions are often the user's own creations and thus should be kept in a more visible, backup-friendly location. On the other hand, maybe most power users don't install AutoHotkey in the Program Files directory, opting instead to decompress the ZIP file somewhere. If that seems likely enough to you, we could have a poll to find out.I don't like programs messing with My Documents and splitting AHK into multiple dirs around. Its enough to search A_AHKPATH\Include & A_AHKPath\Include-User. I don't see use for My Doc/Include. I don't beleive anybody outthere will have includes by user profile. We are not talking here about picture sharing.
MyDocs/Include is overkill?
I meant the user-includes directory, not the stdlib. Doing recursive search will lead to bugs and misbehavior even among power users due to accidentally having multiple functions of the same name. It would also reduce performance slightly. On the other hand, I see that it's a big benefit to organization; so I'm not fundamentally opposed to it. Perhaps another poll at some point...First one found should be used, so other will not be accessible at all, the same as with user overrides...
I'd considered this but it will lead to ambiguity if two or more identically-named files exist in various subdirectories.
Good idea, but I think that it should be deferred until after the initial release, and only if there's demand.
Perhaps some log can be created so ppl know what functions are accutally included.
Good point, but it's getting a bit too complicated for my taste. Since the function-searching will restrict files to *.ahk, maybe that will be enough of a filter/protection.This is good point. This can be easily solved by not putting things in this folder or reseriving some exclusion char in folder name, for instance _. So, _Doc will not be search.
Another drawback is that it would prevent having any subdirectories that contain files that are unrelated to functions (such as documentation, notes, etc.) So maybe this feature should be Off by default (which would allow it to be deferred until a later release).
I considered this but it seems like overkill (too complicated) for the initial release. Also, recursive search overlaps with it somewhat, so maybe we should just stick to that (assuming users decide it's worthwhile).
Another approach is to keep env var, like proposed AHK_LIB that will keep the paths to be searched. I beleive this approach is the best. If this env var does not exist default behavior can be recursion and if this var exists, AHK should search only paths referenced and like this it works in most other languages.
Actually I was unhappy with double-underscore but it seemed the lesser evil than requiring the program to search again on a class name whenever a function-call containing an underscore doesn't exist as a file. Both performance and professionalism would be negatively impacted, but only if underscores will be common in non-class userlib and stdlib function names (maybe they won't be).
I still think single underscore is better though, as users will have to stick forever with double score, for instance: MMenu__Create(), MMenu__Add()... or RemoteBuf__Open(). But if that makes you happy I wont argue, its trivial detail anyway.
It doesn't seem practical due to Vista and possibly other reasons.Not if there are some safe defaults where this env var is not present, like A_AHKPATH\Include.
However, it has the drawback of adding a dependency to the registry or environment, which reduces the portability of scripts.
I don't follow that. If it's important, please clarify.
Users that want their scripts portable should put their script in this folder or in Include-User folder.
As far as I know, the only two types of persistent environment variables are "user" and "system". We could have a poll to decide whether this feature is necessary, and if so, whether it should be done via registry or environment (as far as I know, those are the only two choices other than some kind of INI file, which is probably a bad idea due to Vista protection).
Also, AHK can register this variable privatly, without adding it to the machine location for env vars. SO this var will always exists, either explicitely or implicitely. Something like this is done by for example Total Command which creates COMMANDER_PATH if it doesn't exist in the system. This didn't introduce portability problems with TC, contrary to that.