all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: master 02bca34: Utilize new string decoding feature in GTK native input
@ 2022-02-19  9:35 Eli Zaretskii
  2022-02-19 10:09 ` Po Lu
  0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2022-02-19  9:35 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: master 02bca34: Utilize new string decoding feature in GTK native input
  2022-02-19  9:35 master 02bca34: Utilize new string decoding feature in GTK native input Eli Zaretskii
@ 2022-02-19 10:09 ` Po Lu
  2022-02-19 12:36   ` Eli Zaretskii
  0 siblings, 1 reply; 4+ messages in thread
From: Po Lu @ 2022-02-19 10:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: master 02bca34: Utilize new string decoding feature in GTK native input
  2022-02-19 10:09 ` Po Lu
@ 2022-02-19 12:36   ` Eli Zaretskii
  2022-02-19 12:49     ` Po Lu
  0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2022-02-19 12:36 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: master 02bca34: Utilize new string decoding feature in GTK native input
  2022-02-19 12:36   ` Eli Zaretskii
@ 2022-02-19 12:49     ` Po Lu
  0 siblings, 0 replies; 4+ messages in thread
From: Po Lu @ 2022-02-19 12:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-02-19 12:49 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-02-19  9:35 master 02bca34: Utilize new string decoding feature in GTK native input Eli Zaretskii
2022-02-19 10:09 ` Po Lu
2022-02-19 12:36   ` Eli Zaretskii
2022-02-19 12:49     ` Po Lu

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.