Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Standard Library (stdlib): Simple file-system approach


  • Please log in to reply
63 replies to this topic

Poll: Should each stdlib function name begin with an underscore? (8 member(s) have cast votes)

Should each stdlib function name begin with an underscore?

  1. Yes, to reduce competition with user function names and indicate at-a-glance that the function is external. (1 votes [12.50%])

    Percentage of vote: 12.50%

  2. No, it's better not to "penalize" stdlib functions in this way. (7 votes [87.50%])

    Percentage of vote: 87.50%

  3. Other (0 votes [0.00%])

    Percentage of vote: 0.00%

Vote Guests cannot vote
Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
(This topic was split off from Corrupt's Ahkx_Include - a Stdlib related application.)

The following is so simple that you've probably already thought of it:

When a call to a nonexistent function is encountered, search the AutoHotkey\Includes folder for a file whose name matches that of the function. If found, automatically include the file.

This approach has an attractive elegance that might outweigh the performance concerns of the one-function-per-file approach. Firstly, it avoids an index.dat file, which reduces future maintenance and simplifies the code. Secondly, it allows new functions to be added to the stdlib simply by copying them into the folder (though it might be best if we have a separate user folder for this purpose, which is described further below).

Here are some other considerations:

If a particular stdlib function calls any private functions (i.e. functions that only it is ever likely to call), those functions can and should be listed inside the same file as the public function. This would reduce the number of stdlib files.

I have some concern about Vista's protection of the Program Files folder. For example, if a non-admin user tries to edit a file anywhere in Program Files, it might not take effect from AutoHotkey's point of view (can anyone verify this?). If this is true, it would probably be documented as a known issue.

Each stdlib function should probably start with an underscore to reduce collisions in the global namespace. However, this wouldn't be mandatory: the user would be free to copy non-underscore functions into that directory. Better yet, the user could keep their own functions in their own user-includes folder, which would be searched by AutoHotkey prior to searching the stdlib folder.

The user-includes folder could perhaps default to "My Documents\AutoHotkey Include" (putting it in Program Files seems unprofessional for various reasons, not the least of which is Vista's safeguards). However, the user would be able to override this location via a new directive.

In summary, although I don't like the performance overhead of this approach, its simplicity, maintainability, and elegance make it fairly compelling.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

The following is so simple that you've both probably thought of it:

When a call to a nonexistent function is encountered, search the AutoHotkey\Includes folder for a file whose name matches that of the function. If found, automatically include the file.

I was going to use that approach with the current version I'm using and I started coding it that way but the problem that I ran into is that functions can have characters that are not currently supported in filenames. Substitute characters could likely be used and/or other workarounds but these methods seemed just as time consuming and less flexible than looking up a name in a list unfortunately. It might still be a better way to go but I had decided to give the lookup method a try since the entire index.dat file could be loaded into a variable and searched in memory. On the other hand, maybe the documentation could state that only certain characters can be used for StdLib function names.

Here are some other considerations:

If a particular stdlib function calls any private functions (i.e. functions that only it is ever likely to call), those functions can and should be listed inside the same file as the public function. This would reduce the number of stdlib files.

I agree but then care should be taken that those functions do not exist elsewhere in other files in the Library to avoid accidentally adding the same function twice. This is why I was originally thinking that a file that has several functions should only be created when absolutely necessary.

I have some concern about Vista's protection of the Program Files folder. For example, if a non-admin user tries to edit a file anywhere in Program Files, it might not take effect from AutoHotkey's point of view (can anyone verify this?). If this is true, it would probably be documented as a known issue.

Confirmed, that users will have difficulty with write permissions in the Program Files directory in general. AutoHotkey will also have issues trying to wite to files in its own folder. This is why I suggested installing the version I put together to a folder where a user has write access.

Each stdlib function should probably start with an underscore to reduce collisions in the global namespace. However, this wouldn't be mandatory: the user would be free to copy non-underscore functions into that directory. Better yet, the user could keep their own functions in their own user-includes folder, which would be searched by AutoHotkey prior to searching the stdlib folder.

If we decide to remove the need for an index.dat file then might be a good idea to help separate user files from Standard Library files to make things easier to update but searching 2 separate directories for each file would take longer. A file listing could be generated for each directory at startup then compared in memory to help speed up the process but loading an index.dat file and merging in a user.dat file in memory might ned up being a bit faster.

The user-includes folder could perhaps default to "My Documents\AutoHotkey Include" (putting it in Program Files seems unprofessional for various reasons, not the least of which is Vista's safeguards). However, the user would be able to override this location via a new directive.

I was thinking about changing the location to something similar by default with the installer I put together also since I'm running Vista a lot of the time these days.

In summary, although I don't like the performance overhead of this approach, its simplicity, maintainability, and elegance make it fairly compelling.

Well, the delay in startup using a preprocessor seems reasonable so far and I'm hoping that the performance would be at least twice the speed (if not faster) so it might not be much of an issue.

Edit: added to thoughts on function names and Vista issues

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

...functions can have characters that are not currently supported in filenames... maybe the documentation could state that only certain characters can be used for StdLib function names.

I don't think this would be an issue for the stdlib since such function names would be "officially" reviewed by me or someone else prior to distribution with AutoHotkey. I think the names should probably be limited to alphanumeric and underscore (for consistency and readability). Custom/user functions might be more of an issue, but I think a note in the documentation would be enough to clarify it.

...care should be taken that those [private] functions do not exist elsewhere in other files in the Library to avoid accidentally adding the same function twice.

That's a good point -- so function designers should choose private names that are extremely unlikely to match the names of other functions.

AutoHotkey will also have issues trying to wite to files in its own folder. This is why I suggested installing the version I put together to a folder where a user has write access.

I don't envision any need for AutoHotkey.exe to write anything there. By contrast, the AutoHotkey installer does write things there, but it has admin permission so it seems okay.

...searching 2 separate directories for each file would take longer. A file listing could be generated for each directory at startup then compared in memory to help speed up the process but loading an index.dat file and merging in a user.dat file in memory might ned up being a bit faster.

This seems unnecessary and might even make performance worse because NTFS has high-performance filename lookups. Although some systems still use Fat32 (which performs worse in lookups), Fat32 is becoming increasingly rare.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

...searching 2 separate directories for each file would take longer. A file listing could be generated for each directory at startup then compared in memory to help speed up the process but loading an index.dat file and merging in a user.dat file in memory might ned up being a bit faster.

This seems unnecessary and might even make performance worse because NTFS has high-performance filename lookups. Although some systems still use Fat32 (which performs worse in lookups), Fat32 is becoming increasingly rare.

I'm not sure about this one. I think we should probably put something together to test. Each directory (Standard Library in Program Files folder? and User Functions in user's folder?) would need to be searched to see if each file exists for each function. I'm not sure if that would be any faster than searching for text in a variable to retrieve the filename to include. I have a feeling that searching in a variable might give more consistent results on most systems but I'm not sure. Either method sounds ok to me though...

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Each directory (Standard Library in Program Files folder? and User Functions in user's folder?) would need to be searched to see if each file exists for each function.

Upon opening a file in a particular directory, the file system instantly caches the directory so that subsequent requests for other files in the same directory incur no disk reads. In addition, NTFS excels at filename lookups; I can say from experience that it is dramatically faster than Fat32 in this area, especially when the target folder contains hundreds of files. NTFS employs data structures and algorithms that are likely far superior to the crude binary search method I'd be likely to implement.

So I don't think the performance needs to be compared vs. the methods you described; but if you wish simulate/test it somehow, I'd be interested in your findings.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
Is this typical for all folders on NTFS though or just for indexed locations? The reason I ask this is because Indexed locations are definitely faster to search than non-indexed locations on Vista. Honestly, I haven't looked into how the OS treats files differently on NTFS vs FAT32 that deeply other than basic aspects like partition/file size limitations.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Jul 29 2016 12:40 AM
  • Joined: 24 May 2006
OK, so 1-1 strikes back :D.

Fine, we have agrement then.
Posted Image

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

Fine, we have agrement then.

It sounds like it (although others haven't chimed in and although you may have been referring to 1-1 for functions/files only...). In an attempt to summarize: - A new directive would be added(?). Something like #AutoIncludeFunctions or #StdLib so that only StdLib scripts experience any performance reduction(?)

- AutoHotkey would determine function references for which a user has not included a function for. These functions would be named using an underscore as a prefix (for functions included with the distribution) and only alpha numeric characters would be used for function names

- AutoHotkey would then search for a file with the same name as the function (with a .ahk extension?). First in an /Include subdirectory in the same folder as autohotkey.exe(?) then in an /AutoHotkey/Include subdirectory in the user's documents folder(?) and #Include the file if found (always added to the end of a script?)

- the directories should contain 1 function per file (whenever possible) with the filename being the same as the function name (extension?). If the function must depend on other functions then the other functions should be included in the same file but have unique function names to avoid conflicts with other functions that are buried in other files in the Library (maybe using a _* prefix to make them easy to find since * can't be used in a filename?)Does this sound like a good game plan?

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Is this [high performance] typical for all folders on NTFS though or just for indexed locations? The reason I ask this is because Indexed locations are definitely faster to search than non-indexed locations on Vista.

This high performance applies to plain NTFS: no indexing service is necessary. And when I say "lookup", it's not really a search in the sense of Search Companion. It's whenever you ask the file system to open an explicitly-named file. How long the file system takes to respond is the important factor. NTFS is very fast in this respect, except for the very first access to a particular directory (which if uncached requires some disk seeks). After the first access, the entire directory is generally in the cache, so subsequent lookups are essentially instantaneous.

A new directive would be added(?). Something like #AutoIncludeFunctions or #StdLib so that only StdLib scripts experience any performance reduction(?)

That doesn't seem necessary because the program will only search for an external function when it's about to display an error dialog "call to nonexistent function". Once a particular external function is found and auto-included, no further external seeking need ever be done for that particular function.

These functions would be named using an underscore as a prefix (for functions included with the distribution)

This should be discussed more here and/or publicly in Wish List. I've added a poll to help attract more discussion.

AutoHotkey would then search for a file with the same name as the function (with a .ahk extension?).

Having a .ahk extension seems desirable.

First in an /Include subdirectory in the same folder as autohotkey.exe(?) then in an /AutoHotkey/Include subdirectory in the user's documents folder(?)

I think it should probably be in the opposite order: the user's folder first. This would allow the user to override stdlib functions, or update them to newer/better versions without having to alter the stdlib files in Program Files.

...and #Include the file if found (always added to the end of a script?)

Yes, it seems best to include the file at the end of the script to avoid changing the line numbers seen in ListLines. This would also allow stdlib files to include subroutines without risk of interference with the auto-execute section.

maybe using a _* prefix to make [private functions] easy to find since * can't be used in a filename?)

We should probably avoid special chars because they may lead to compatibility problems with v2 and external tools such as syntax highlighters.

Finally, I think you gave a good summary. Although I'm not yet certain this plan will be implemented, it's the one I like the best at the moment.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

A new directive would be added(?). Something like #AutoIncludeFunctions or #StdLib so that only StdLib scripts experience any performance reduction(?)

That doesn't seem necessary because the program will only search for an external function when it's about to display an error dialog "call to nonexistent function". Once a particular external function is found and auto-included, no further external seeking need ever be done for that particular function.

I like the idea of having it turned on by default also but I was thinking that someone might want the ability to turn auto-inclusion off. Maybe not...

First in an /Include subdirectory in the same folder as autohotkey.exe(?) then in an /AutoHotkey/Include subdirectory in the user's documents folder(?)

I think it should probably be in the opposite order: the user's folder first. This would allow the user to override stdlib functions, or update them to newer/better versions without having to alter the stdlib files in Program Files.

That makes sense but may lead to confusion if scripts are posted in the forum that use a modified StdLib function without including the modified version. They may forget that they had created a modified version previously. It might help to suggest to people to create a modified version with a slightly different name and add it to their /AutoHotkey/Include user functions folder instead of modifying the original. They might go ahead and modify the original anyway, but then they would risk that updates to the Standard Library could overwrite their changes. Another issue could be someone adding a modified function to their user functions directory to use with a specific script then forgetting and wondering why other scripts no longer work as expected (even if they re-install AutoHotkey). The answer to that might be that they have to go through their user functions and figure out what changes they have made to any functions that might have the same name as Standard Library functions but it might be easier to fix the potential issue by forcing Standard Library functions to always override user functions. A user could still override a Standard Library function by adding the modified function in their code since AutoHotkey would not try to include the function if it already existed.

maybe using a _* prefix to make [private functions] easy to find since * can't be used in a filename?)

We should probably avoid special chars because they may lead to compatibility problems with v2 and external tools such as syntax highlighters.

Good point, but it may help keep things consistent by specifying a standard prefix to use to minimize collisions with others names used. Maybe two underscores (or three?) instead of one for private function names? __MyInternalFunction

Finally, I think you gave a good summary. Although I'm not yet certain this plan will be implemented, it's the one I like the best at the moment.

This sounds good to me so far. Since I usually like to have something to test with for fun, I'll make the necessary changes in the Ahkx_Include preprocessor for anyone that's interested in testing a working model.

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004
An alternate version of Ahkx_Include can be downloaded here for testing that has the functionality listed above. The installer for this version will set up the .ahkx extension and the /Include directories in the AutoHotkey directory and MyDocuments folder. The installer does not attempt to locate your AutoHotkey installation folder so please correct the installation path to specify to install in your AutoHotkey directory if you have installed AutoHotkey in a different location.

The .zip file also includes a couple test functions. As with the previous version, I would suggest either creating a new .ahkx file or copying an existing .ahk file then renaming with a .ahkx extension for testing since ahkx.exe will add #Include lines to the end of a script that is executed if necessary.

The /AutoHotkey/Include folder in MyDocuments will be searched for functions first as Chris had suggested, then the /Program Files/AutoHotkey/Include folder.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Jul 29 2016 12:40 AM
  • Joined: 24 May 2006
I more or less agree with Chris on everything said above. Just several notes I would like to add after reading all that, without quoting anything particular.

[*:3874ak6a] 2 Folders are OK. UserInclude & Include with UI searched first. Besides that recursive search would be nice to have for the sake of stdlib and user lib organisation. Speed will stay the same if there are no additional dirs but if the user want so, he must be able to use sub dirs to organise. Anything else is overkill, like MyDocs/Include and/or additional directives.

[*:3874ak6a] _ prefix is not needed, IMO.

[*:3874ak6a] private functions, those used by stdlib internaly but not exposed to users, have to be thought out with more detail, but I will leave this for later.

[*:3874ak6a] Absence of index.dat introduced new problem although easily solvable with some simple rules in function naming. There should be some form of class declaration. 1-1 principle is not at all good for includes like MMenu and generaly to modules that expose number of functions that are to be used together. For instance, if the one used MMenu_Create, add entire MMenu module residing in the MMenu.ahk file. Contray to that, sticking to the 1-1 rule here will complicate module so much, that I wouldn't even know how to maintain it any more. In my work, I used this mechanism - there is a variable classSeparator that I set to be "_". If func X_Y is not found then if X_Y.ahk doesn't exist, check if X.ahk alone exists and if so, add it. Without this, many modules will be very hard to maintain, so will for writting more complex modlues then those being simple functions will be very low.

[*:3874ak6a] Hidding globals that stdlib uses can be also handled later.

The everything said so far by 3 of us iis slight variation of wish I made here :

I suggest to modify #include so to search recursively folder pointed by env var AHK_LIBRARY (if it exists) for include files.

...and if there is no include at all, script should search default AHK_LIB place [for instance A_AHKPATH\Library]

You remember that I freeked out as you didn't realise that I acctually want the same thing we are trying to achieve now :D


When performance is in question, this will be fast as NTFS is designed so random file access is the fastest operation (which is exactly what will be happening in the background). FAT32 will be slower but its dead anyway. Other things that are side effects of 1-1 principle are more or less trivial and will not influence the speed noticebly [for instance, lot of small files that stdlib will have will certanly fall bellow minimal memory size (claster) handled by OS so stdlib will ocupy more memory and hard disk reading head will have to read more data, etc..]
Posted Image

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

[Searching user-includes first] makes sense but may lead to confusion if scripts are posted in the forum that use a modified StdLib function without including the modified version. They may forget that they had created a modified version previously. It might help to suggest to people to create a modified version with a slightly different name and add it to their /AutoHotkey/Include user functions folder instead of modifying the original. They might go ahead and modify the original anyway, but then they would risk that updates to the Standard Library could overwrite their changes. Another issue could be someone adding a modified function to their user functions directory to use with a specific script then forgetting and wondering why other scripts no longer work as expected (even if they re-install AutoHotkey). The answer to that might be that they have to go through their user functions and figure out what changes they have made to any functions that might have the same name as Standard Library functions but it might be easier to fix the potential issue by forcing Standard Library functions to always override user functions. A user could still override a Standard Library function by adding the modified function in their code since AutoHotkey would not try to include the function if it already existed.

It's not an easy decision. However, I think the user-includes directory is something of a power-user feature (most casual users probably won't even have such a directory). I don't think power users need as much protection against such accidents. In any case, we could have a public poll/discussion about it if it seems worthwhile.

maybe using a _* prefix to make [private functions] easy to find since * can't be used in a filename?)

We should probably avoid special chars because they may lead to compatibility problems with v2 and external tools such as syntax highlighters.

Good point, but it may help keep things consistent by specifying a standard prefix to use to minimize collisions with others names used. Maybe two underscores (or three?) instead of one for private function names? __MyInternalFunction

That's a good approach, though maybe it shouldn't be mandatory. As long as the name is fairly long and distinct, it should be okay.

An alternate version of Ahkx_Include can be downloaded here for testing that has the functionality listed above.

Thanks for that.

recursive search would be nice to have for the sake of stdlib and user lib organisation. Speed will stay the same if there are no additional dirs but if the user want so, he must be able to use sub dirs to organise.

I'd considered this but it will lead to ambiguity if two or more identically-named files exist in various subdirectories. 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).

Anything else is overkill, like MyDocs/Include and/or additional directives.

MyDocs/Include is overkill?

There should be some form of class declaration. 1-1 principle is not at all good for includes like MMenu and generaly to modules that expose number of functions that are to be used together. For instance, if the one used MMenu_Create, add entire MMenu module residing in the MMenu.ahk file. Contray to that, sticking to the 1-1 rule here will complicate module so much, that I wouldn't even know how to maintain it any more. In my work, I used this mechanism - there is a variable classSeparator that I set to be "_". If func X_Y is not found then if X_Y.ahk doesn't exist, check if X.ahk alone exists and if so, add it. Without this, many modules will be very hard to maintain, so will for writting more complex modlues then those being simple functions will be very low.

That is a good point. Perhaps two consecutive underscores can be used to separate the class name from its function name. That would help cut down on ambiguity and reduce the chance that a particular function name accidentally matches both a class filename and an ordinary function.

I suggest to modify #include so to search recursively folder pointed by env var AHK_LIBRARY (if it exists) for include files.
...and if there is no include at all, script should search default AHK_LIB place [for instance A_AHKPATH\Library]

Yes, having an environment variable or registry entry that indicates an override path for the stdlib and/or userlib can still be done if it adds enough value. It would avoid the need for the user to add a user-path override at the top of every script. However, it has the drawback of adding a dependency to the registry or environment, which reduces the portability of scripts.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Jul 29 2016 12:40 AM
  • Joined: 24 May 2006

MyDocs/Include is overkill?

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.

I'd considered this but it will lead to ambiguity if two or more identically-named files exist in various subdirectories.

.
First one found should be used, so other will not be accessible at all, the same as with user overrides... StdLib will be maintained by serious ppl so such trivial errors will not be in official distro, the same as some other corrupt mention. Ordinary users will probably don't touch Includes folder ever, and advanced users are advanced for a reason. So let me requote your own words:

I don't think power users need as much protection against such accidents.

Most of things mentioned above are of such triviality that you don't have to be power user to see that. Perhaps some log can be created so ppl know what functions are accutally included.

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).

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 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.

That is a good point. Perhaps two consecutive underscores can be used to separate the class name from its function name. That would help cut down on ambiguity and reduce the chance that a particular function name accidentally matches both a class filename and an ordinary function.

Whatever you like and see good to use is fine. I used _ in my work as it fills natural for me and in most code I read around, ppl usualy use underscore to simulate some kind of classes where not possible (for instance, in C).
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.


However, it has the drawback of adding a dependency to the registry or environment, which reduces the portability of scripts.

Not if there are some safe defaults where this env var is not present, like A_AHKPATH\Include. Users that want their scripts portable should put their script in this folder or in Include-User folder. 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.
Posted Image

corrupt
  • Members
  • 2558 posts
  • Last active: Nov 01 2014 03:23 PM
  • Joined: 29 Dec 2004

MyDocs/Include is overkill?

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.

This is necessary since Vista does not allow users permission to modify files in their /Program Files directory by default.

I'd considered this but it will lead to ambiguity if two or more identically-named files exist in various subdirectories.

.
First one found should be used, so other will not be accessible at all, the same as with user overrides... StdLib will be maintained by serious ppl so such trivial errors will not be in official distro, the same as some other corrupt mention. Ordinary users will probably don't touch Includes folder ever, and advanced users are advanced for a reason. So let me requote your own words:

I don't think power users need as much protection against such accidents.

I don't see this as being an "advanced users only" type of feature (StdLib in general). Average or new users will not need to know any advanced information on programming to use this feature. They will only need to know that if they copy "this file" into "this folder" that they can then use "this function" in their scripts. They don't even need to know what the file they are adding does. With this is mind, the protection would be for "new - average users".

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).

This is good point.

It wouldn't actually. The mechanism we discussed would only include .ahk files so other files with other extensions could be added to the directory without any issues.


The problem I see with allowing a registry entry to override the user path and or allowing the documents folder location to override the standard library location is in running a script from a removable device. I have a memory drive that I use that has a directory with scripts and a copy of autohotkey.exe. I can modify and create scripts easily that way for use on someone else's PC then just drag and drop them onto the autohotkey.exe file to execute (I don't even have to use notepad to edit. JFE can be used which allows syntax highlighting and buttons can be programmed for executing scripts instead of having to drag and drop). Since this is for convenience, it would be great to use standard library functions to save the time of having to add an include path and/or include a particular function. The problem I will run into though is that, if a user has a function with the same name in their user directory it will override a function that I have included on the memory drive in the /Include folder where autohotkey.exe resides. The same would be true for a registry entry. That's no good.

Forcing the standard library functions to override user functions might also be handy in cases where a system administrator might want to make a change to a function that could affect scripts for multiple users on a network without allowing the user permissions to override the changes.