Register + Unicode (was Re: emojis everywhere...)

Eric Siegerman pub08-gnc at
Sat Apr 7 16:26:52 EDT 2018

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

        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

An e-acute it treated like "5a" above (even if I don't type any
        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:
  - Autosplit Ledger mode in effect for the account in question

Nitpicky details, to be sure.  Is any of it worth filing a bug

  - Eric

More information about the gnucash-devel mailing list