really the only thing that makes sense. the query import module declaration cannot always know the path, so it might need the preload. but with preload you still want the import declaration for processors that cannot preload

fix global, mutable variables set by functions in imported modules not being available within the calling query; still print variables when some where set when we do not expect it, because static analysis failed to find the assignment (e.g. in case of these function calls)

perhaps fpc has fixed their parser

improve multipage template usability: prevent it from being overriden by option wraparound; pattern paths are relative to template not calling directory; honor --silent

fix support library version in build.gradle, because google's newest version does not work on Android <= 13 anymore

rather than CP-0 for default encoding

refactor string encoding conversions: add Windows-1252 as its own encoding (rather than treating it as latin1). Add ASCII encoding. Rename strChangeEncoding to strConvert. Remove optimized UTF-8 <-> UTF-16/32 conversion. Set codepages on the resulting strings for fpc 3.x. Improved checking for invalid utf-8 input. Add function registerFallbackUnicodeConversion to register my functions as encoding converter in the widestring manager, so that compiler implicit encoding conversions to latin-1/1252 work without a separate widestring manager library.

incompleted changes, but can't have uncommited modifications when syncing to new computer

fix that x:system only read stdout and thus a called program writing a lot to stderr became blocked once the pipe was full

everyone uses append

track of charset of the webpages through form request objects, so utf-8 and latin1 pages can receive differently encoded data.