Modifying text input methods. Will affect platform layers.

[Neil Hodgson]

Feature request #1293 proposes changing the way that platform layers communicate text input like typing to the platform-independent code. This will, at some point, require changes to platform layer code so we need to decide when this will happen and how the transition is managed.

The method used for text input is Editor::AddCharUTF and the corresponding ScintillaBase::AddCharUTF which handles autocompletion then calls Editor::AddCharUTF. Both currently take three arguments: text, length, and whether to treat the text as DBCS.

The proposal first removes the ‘treatAsDBCS’ argument and relies only on Document::dbcsCodePage to control how the input character is reported in the SCN_CHARADDED notification. The ‘treatAsDBCS’ argument has had a confused and inconsistent history and the new behaviour will be more consistent between input methods and platforms.

Further changes use a std::string_view instead of separate text and length arguments. Using a single argument is clearer and can simplify calling code. As calling code has to change to the new signature, there is an opportunity to clarify the method name with InsertCharacter my preference.

Making this change now unconditionally could break existing builds until each platform layer is updated so the intention is to retain ScintillaBase::AddCharUTF for some time and call InsertCharacter in ScintillaBase::AddCharUTF. We need to decide when to remove ScintillaBase::AddCharUTF and, before that, if and when to mark ScintillaBase::AddCharUTF as [[deprecated]]. Editor::AddCharUTF is not called directly by any of the bundled platform layers so can be removed. It is possible that platform layer maintainers may have other concerns.

We should decide whether to use [[deprecated]] in cases like this. The effect of [[deprecated]] is to cause the compiler to print a warning for any call to the deprecated method or function. The build will normally still succeed and the method will work. Downstream projects may use different compiler flags causing the build to fail. [[deprecated]] is from C++14 so may be a problem for LongTerm3.

https://sourceforge.net/p/scintilla/feature-requests/1293/

Neil

[Mitchell]

Hi,

On Fri, 31 May 2019, 'Neil Hodgson' via scintilla-interest wrote:

> Feature request #1293 proposes changing the way that platform layers communicate text input like typing to the platform-independent code. This will, at some point, require changes to platform layer code so we need to decide when this will happen and how the transition is managed.
>
> The method used for text input is Editor::AddCharUTF and the corresponding ScintillaBase::AddCharUTF which handles autocompletion then calls Editor::AddCharUTF. Both currently take three arguments: text, length, and whether to treat the text as DBCS.
>
> The proposal first removes the ‘treatAsDBCS’ argument and relies only on Document::dbcsCodePage to control how the input character is reported in the SCN_CHARADDED notification. The ‘treatAsDBCS’ argument has had a confused and inconsistent history and the new behaviour will be more consistent between input methods and platforms.
>
> Further changes use a std::string_view instead of separate text and length arguments. Using a single argument is clearer and can simplify calling code. As calling code has to change to the new signature, there is an opportunity to clarify the method name with InsertCharacter my preference.

For LongTerm3, which cannot use C++17's std::string_view(), it is likely that any platform interface changes will simply be to rename 'AddCharUTF' to 'InsertCharacter', and drop the last 'treatAsDBCS' argument.

> Making this change now unconditionally could break existing builds until each platform layer is updated so the intention is to retain ScintillaBase::AddCharUTF for some time and call InsertCharacter in ScintillaBase::AddCharUTF. We need to decide when to remove ScintillaBase::AddCharUTF and, before that, if and when to mark ScintillaBase::AddCharUTF as [[deprecated]]. Editor::AddCharUTF is not called directly by any of the bundled platform layers so can be removed. It is possible that platform layer maintainers may have other concerns.

As the maintainer of the curses (terminal) platform layer, I don't have any concerns.

> We should decide whether to use [[deprecated]] in cases like this. The effect of [[deprecated]] is to cause the compiler to print a warning for any call to the deprecated method or function. The build will normally still succeed and the method will work. Downstream projects may use different compiler flags causing the build to fail. [[deprecated]] is from C++14 so may be a problem for LongTerm3.

Yes, LongTerm3 cannot use a compiler warning. Just a bullet in the release notes is probably sufficient, since any compiler failures will likely just be the need to rename a function and drop an optional third argument.

I don't have a preference for when this should happen. It can be anytime.

Cheers,
Mitchell