> I'm sorry to bother you, but the behaviour of lua GetSelText function has changed.
> The returned string now always include the terminating 0.
In previous versions of SciTE, string results from Scintilla API calls that included NUL bytes were truncated early at the NUL. A change was made to pass the whole string including any NUL bytes.
There have been some inconsistencies in the way that string returning APIs were handled by Scintilla, particularly SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE. Most APIs return the length of the string excluding any NUL byte terminator but the mentioned APIs returned one more, including the NUL.
It is likely best to change these 3 APIs to be consistent with others. However, this could break applications that will no longer allocate enough memory to include the NUL terminator. Downstream projects should check their use of these APIs.
The normal technique is to call the Scintilla API with NULL as the string argument which returns the length. Then allocate a string of length+1 bytes (the +1 may be set to NUL). Then call the API with this allocated string. Use the resulting string in a way that ignores the trailing NUL. If using the C++ std::string type, an extra NUL byte is automatically allocated at the end which is not counted in std::string::length() so works without problems.
The attached LengthFix.patch changes Scintilla to return the string length for the 3 above mentioned APIs.
The attached LengthFixSciTE.patch changes the Lua Scintilla interface to return an empty string instead of nil when the API returns an empty string. This was previously hidden by the +1 on the length.
> As a consequence, even no selection at all gets length=1.
> Many scripts of mine are broken, but I have already reverted to the previous version.
> Nonetheless, somebody could get strange results.
The above changes modify behaviour too much to be pushed in a quick update, so users should either strip terminating NULs off API results or return to the previous SciTE release for now.