Re: master 02bca34: Utilize new string decoding feature in GTK native input

Re: master 02bca34: Utilize new string decoding feature in GTK native input

[Eli Zaretskii]

> commit 02bca34852b1f9dd2b3e5364274452d377686f6a
> Author:     Po Lu <luangruo@yahoo.com>
> AuthorDate: Sat Feb 19 09:18:27 2022 +0800
> Commit:     Po Lu <luangruo@yahoo.com>
> CommitDate: Sat Feb 19 09:18:27 2022 +0800
> 
>     Utilize new string decoding feature in GTK native input
> 
>     * src/gtkutil.c (xg_im_context_commit): Don't decode strings
>     manually using g_utf8_to_ucs4 but pass unibyte string as the
>     keystroke event arg instead.

Is this a good idea?  Consing a string when we process input increases
GC pressure, and what issues does this change solve as a
counter-weight for that disadvantage?  Is g_utf8_to_ucs4 a problematic
API or something?  If so, we could use our own implementation
instead.  But in general, decoding UTF-8 encoded C string is better
done without consing a string and then using the coding.c stuff.
After all, if the original string is 100% guaranteed to be in UTF-8,
the decoding is almost trivial.

Re: master 02bca34: Utilize new string decoding feature in GTK native input

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this a good idea?  Consing a string when we process input increases
> GC pressure, and what issues does this change solve as a
> counter-weight for that disadvantage?  Is g_utf8_to_ucs4 a problematic
> API or something?

No, but some input method modules don't always return valid UTF-8 like
they're supposed to, thereby causing crashes in g_utf8_to_ucs4_fast.

I should have explained that in the commit message.

> But in general, decoding UTF-8 encoded C string is better done without
> consing a string and then using the coding.c stuff.  After all, if the
> original string is 100% guaranteed to be in UTF-8, the decoding is
> almost trivial.

It's supposedly guaranteed, but some input method modules break that
guarantee.

Thanks.

Re: master 02bca34: Utilize new string decoding feature in GTK native input

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 19 Feb 2022 18:09:38 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is this a good idea?  Consing a string when we process input increases
> > GC pressure, and what issues does this change solve as a
> > counter-weight for that disadvantage?  Is g_utf8_to_ucs4 a problematic
> > API or something?
> 
> No, but some input method modules don't always return valid UTF-8 like
> they're supposed to, thereby causing crashes in g_utf8_to_ucs4_fast.
> 
> I should have explained that in the commit message.

You can still explain that in a comment to the code.

> > But in general, decoding UTF-8 encoded C string is better done without
> > consing a string and then using the coding.c stuff.  After all, if the
> > original string is 100% guaranteed to be in UTF-8, the decoding is
> > almost trivial.
> 
> It's supposedly guaranteed, but some input method modules break that
> guarantee.

And what do we want to do with those invalid UTF-8 sequences?  The way
you did it will produce raw bytes for them -- is that really TRT in
this case?

In any case, at the very least consider using decode_string_utf_8
instead of consing a Lisp string and then using the "usual" decoding
stuff -- decode_string_utf_8 will cons only one string.

Re: master 02bca34: Utilize new string decoding feature in GTK native input

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> You can still explain that in a comment to the code.

Thanks, will do.

> And what do we want to do with those invalid UTF-8 sequences?  The way
> you did it will produce raw bytes for them -- is that really TRT in
> this case?

Yes, it'll alert the user that something has gone wrong with the input
method.

> In any case, at the very least consider using decode_string_utf_8
> instead of consing a Lisp string and then using the "usual" decoding
> stuff -- decode_string_utf_8 will cons only one string.

I will look into that.