Regarding the mixing of text and non-text features in a single plugin due to shared low-level routines, you could put the shared routines in a separate DLL loaded automatically when either of its callers is loaded, which would make total memory usage nearly the same as now, but this would not be consistent with the independence of each plugin, and would require installers for most anyone not a professional programmer. Possibly a different name reflecting the greater generality?
Another desired set of enhancements for
SAVEARRAY and
LOADARRAY would be
1/ the ability to save or load a part of the array only, specified in the manner of Fortran:
savearray [/o] myarray[3:9] myarrayfile
where the 3:9 are inclusive element offsets
2/ use another array instead of a file for saving to/loading from.
In general, it would be nice to have some array operators, similar to the matrix manipulation routines available in some HLLs.
4/ @inivalue needs a matching function to update .INI files. Such a function should be able to accept an empty "section" as "before the first section header" just as @inivalue, be able to delete or modify an existing line, or insert a new line at any specific location - including "before the first occurrence of section/enty" or "after the last occurrence of section/entry".
I agree that that would be a great feature, but at this point I don't know how to implement it! It's probably a much more complex exercise than just reading.
Undoubtedly very much more complex because it requires modification of the file. Basically it is a file editing function, which can change the middle of a file, and that cannot be done without first saving and then rewriting the rest of the file. If the file were mapped into an array, one whole line per array element, and if we had commands to copy partial arrays, this would be simple.
