[GNC-dev] Register + Unicode (was Re: emojis everywhere...)

[John Ralls]

> On Apr 7, 2018, at 1:26 PM, Eric Siegerman <pub08-gnc at davor.org> wrote:
> 
> On Sat, Apr 07, 2018 at 07:31:38AM -0700, John Ralls wrote:
>>> On Apr 6, 2018, at 11:11 PM, Wm via gnucash-devel <gnucash-devel at gnucash.org> wrote:
>>> gnc 3.0 allows emojis in places I think inappropriate
> 
> In poking at this, I've discovered some inconsistency in the
> register's handling of (what I believe to be) invalid input.
> This isn't new; it's the same in GNC 3.0 and 2.6.18.
> 
> In a text field (I've tested a txn's description and a split's
> memo), both U+e9 ("é", e-acute) and U+1f600 ("😀", grinning-face
> emoji) are accepted, displayed, and stored correctly as UTF-8 by
> the XML back end.  OK so far.
> 
> But in a currency-amount field (I've tested specifically a
> split's Debit field, and all of the following cases are described
> in those terms):
>        I type          Result
>        ======          ======
> 
>        abcd<ENTER>     Each of these behaves like "0<WHICHEVER>":
> 	abcd<TAB>	  - Debit becomes blank (ie. zero)
> 			  - Focus moves as appropriate for
> 			    <WHICHEVER>
> 
>        a5		as above
> 
> 	5a<ENTER>	Nothing happens.  The Debit field
> 			containing "5a" remains focused, even
> 			after repeated <ENTER>s
> 
> 	5a<TAB>		1. I get an error dialog: "An error
> 			   occurred while processing 5a."
> 
> 			2. When I dismiss the dialog, GNC focuses
> 			   the Credit field, leaving the
> 			   "5a" in the Debit field (the former
> 			   is somewhat surprising; the latter
> 			   very much so!)
> 
> 			3. When I then <TAB> or <ENTER> out of
> 			   the Credit field, Debit returns to its
> 			   previous value
> 			     - N.B.: This is unlike "abcd<TAB>",
> 			       which sets Debit to zero
> 			       unconditionally
> 
> An e-acute it treated like "5a" above (even if I don't type any
> digits):
>        abécd<ENTER>    As for "5a<ENTER>" (except that the cursor
> 			jumps to just before the offending "é")
> 
>        abécd<TAB>      As for "5a<TAB>"
> 
> If I repeat the previous two cases with the grinning-face emoji
> (U+1f600) in place of the e-acute, the emoji is ignored
> completely -- it doesn't display, and exiting the field behaves
> as if I'd typed "abcd", i.e. as if I'd typed nothing at all, i.e.
> it gets forced to zero.
> 
> All of those are invalid inputs for Debit, I presume.  So it's
> not a problem that they're all rejected -- only that they're
> rejected differently.
> 
> Testing context:
>  - Ubuntu 16.04
>  - GNC 3.0 and GNC 2.6.18 (same results with both)
>  - XFCE (not sure if that matters)
>  - Locale-related bits of GNC's environment:
>        LANG=en_US.UTF-8
>        LANGUAGE=en_US
>        LC_COLLATE=C
>  - Autosplit Ledger mode in effect for the account in question
> 
> Nitpicky details, to be sure.  Is any of it worth filing a bug
> about?

Depends on what you see as the bug. I suppose there should be a message box when you hit <Enter> instead of just leaving you focused on the erroneous field with no clue that GnuCash is declining to process your bogus input.

Another problem that you didn’t explore is that GnuCash may recognize only code points 0x2b-0x39 as numbers, delimiters, and operators, so users trying to use localized number representations may fail. That would be a libc failure rather than a GnuCash one, but I don’t have a lot of confidence in libc’s localization mechanisms. Perhaps fortunately I think most of the world is resigned to using European numbers and symbols for representing money.

Regards,
John Ralls