Op zaterdag 7 april 2018 22:26:52 CEST schreef Eric Siegerman:
> 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@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?
It think it's worth reporting as a bug, though of low priority.
Geert
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
