lexikos wrote:Library files can be included with the script (using the "local library"), and do not require overwriting global configuration which affects all scripts
A library script of a different(possibly old) version must be overwritten; otherwise, the script relying on it will misbehave. Here, it takes a copy-and-replace task in the same way the configuration/auto-include file needs to be replaced.
Generally, if a library is missed, the program will tell the user that a library is missing, and the script will not run at all. Missing lines in an auto-include will not be so clear.
Not sure about what you mean by
missing lines. I guess you meant
missing files. The point you are making is script misbehaviors caused by different presets and the cause will be less obvious. Then you can just make it show an error message when the specified auto-include/configuration file is missing. It will be as obvious as missing library files.
Copying library scripts into a Lib folder is easier and much less likely to cause conflicts than editing a global configuration or auto-include file. Depending on how the script is packaged, the user may not need to do anything specifically for the libraries.
The same thing. The user just needs a copy of the configuration file and place it alongside
AutoHotkey.exe.
If you worry about the possible conflicts so much, a variable to check preset-configuration path or a list of configuration values could be introduced as well shch that the user can call
msgbox % A_CongigurationPath(or
A_Congigurations/
A_AutoIncludePath) to check whether a configuration/auto-include file is in use or not.
I think you are saying that the script author should distribute the configuration file with their script, but I think you are missing the point.
The point you are addressing is possible conflicts brought by different global settings and these will be less obvious than the library mechanism. So I replied it's a matter of degree. It will be obvious enough to track down conflicts by:
- showing messages if the specified path does not exist
- adding an
A_... variable that indicates the use of this feature.
I imagine light users would stay without enabling this feature and they won't even care such option exists. Those who use this feature should be experienced enough to predict preset conflicts so they will keep different copies of
AutoHotkey.exe and have the plain version of it for testing scripts.
This is a fault of script authors or the lack of a central library repository.
Similarly, conflicts you predict will be a fault of script authors who distribute scripts with required presets.
The design of libraries encourages modularity, whereas your global configuration file suggestion encourages conflicts.
This only applies to those who use only one copy of
AutoHotkey.exe. Some users are not limited to this case.
One can always choose not to use the global configurations. That's why this is suggested to be implemented as an option, not by default. You concern a loss of modilarity with this feature. Ironically, it helps to build a modular system for AutoHotkey-driven programs that support plugins to be added and those plugins can be written in the AutoHotkey language without any required lines.
It was reasonable to assume you were talking about a larger majority of users, who use scripts they find on the forum. Now I suppose you meant users of AutoHotkey vs. users of programs written with AutoHotkey. For the second type, none of this matters.
To make it clear what I mentioned regarding user types, there are two types; one is script writers, namely coders. Another is script executors who just run the script and don't read code. There is one I haven't mentioned but implied (actually they belong to the former) those who add AutoHotkey scripts to an AutoHotkey-driven program as a plugin. For them, requiring even a single line of
#Include will damage their user experience.