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

[Eric Siegerman]

On Fri, Apr 27, 2018 at 02:43:25PM -0400, Eric Siegerman wrote:
> On Fri, Apr 27, 2018 at 03:24:35PM +0200, Geert Janssens wrote:
> > It think it's worth reporting as a bug, though of low priority.
> 
> Done: https://[deleted]

The emojis in my bug report screwed up my previous attempt to
submit this.  I've closed that one and resubmitted it (sans
emojis) as:
https://bugzilla.gnome.org/show_bug.cgi?id=795614

  - Eric
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

> On Apr 27, 2018, at 11:43 AM, Eric Siegerman  wrote:
> 
> On Fri, Apr 27, 2018 at 03:24:35PM +0200, Geert Janssens wrote:
>> It think it's worth reporting as a bug, though of low priority.
> 
> Done: https://bugzilla.gnome.org/show_bug.cgi?id=795613

Well, half-done. You created the bug report but submitted it without finishing 
the description. Please either finish the description or at least provide a 
link to the original post here (please link our archive, not Nabble or GMane).

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Eric Siegerman]

On Fri, Apr 27, 2018 at 03:24:35PM +0200, Geert Janssens wrote:
> It think it's worth reporting as a bug, though of low priority.

Done: https://bugzilla.gnome.org/show_bug.cgi?id=795613

Thanks,
  - Eric
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Geert Janssens]

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
> > >  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 Each of these behaves like "0":
>   abcd - Debit becomes blank (ie. zero)
> - Focus moves as appropriate for
>   
> 
> a5as above
> 
>   5a   Nothing happens.  The Debit field
>   containing "5a" remains focused, even
>   after repeated s
> 
>   5a 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  or  out of
>  the Credit field, Debit returns to its
>  previous value
>- N.B.: This is unlike "abcd",
>  which sets Debit to zero
>  unconditionally
> 
> An e-acute it treated like "5a" above (even if I don't type any
> digits):
> abécdAs for "5a" (except that the cursor
>   jumps to just before the offending "é")
> 
> abécd  As for "5a"
> 
> 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

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

[Wm via gnucash-devel]

On 08/04/2018 07:30, Eric Siegerman wrote:

sensible world view stuff that shouldn't have to be said


[*] We call our numerals "Arabic", but most(?) of the Arab world
actually uses different ones -- somewhat related to ours, but not
closely enough to be very legible to my Anglo eyes.  I believe
ours are descended from a regional variant that was, and is, used
only in parts of North Africa -- and thus in Moorish Spain, from
where the rest of Europe got them.


I think you are being too generous to JohnR, he already knows this and 
just doesn't want to fix stuff immediately after a load of changes.


It is ordinary for him to be defensive if there are a few mistakes.

How about we describe changes and see what happens?

For the record I am frustrated too.

--
Wm



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[Eric Siegerman]

On Sat, Apr 07, 2018 at 08:20:35PM -0700, John Ralls wrote:
> Depends on what you see as the bug.

The bug is the inconsistency.  I have opinions, for what they're
worth, on how it should behave:
  - Reverting to the old value is better than clobbering to zero;
if it can't change the field to what I asked for (because
what I asked for was bogus) it shouldn't change it at all

  - Leaving the bogus input in Debit, and only cleaning it up on
exit from Credit, is kind of ugly and could be confusing

But far outweighing those is that all variations should behave
the *same* way.

None of the current behaviours give incorrect results in the end;
it's just a usability thing -- which is why I called my complaint
nitpicky.

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

What I personally would prefer instead of a dialog that one has
to dismiss is a simple beep, like vi used to do on error, when
you were using an actual serial terminal.  But I pretty much
expect to be outvoted on that...

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

You're right; I can see that being a problem.  If it's libc's
fault, though, it's likely to be platform-dependent, isn't it?
That adds another dimension to the difficulty of trying to fix it
in application code.

> Perhaps fortunately I think most of the world is resigned to using European 
> numbers and symbols for representing money.

Semi-resigned.  I have some souvenir Nepali and UAE currency left
over from a trip, and each country's bills contain both their own
and Western[*] numbers, and their own and English text.  I
suspect you're right, though, that people are rather more
resigned to doing things our way when computers are involved.

[*] We call our numerals "Arabic", but most(?) of the Arab world
actually uses different ones -- somewhat related to ours, but not
closely enough to be very legible to my Anglo eyes.  I believe
ours are descended from a regional variant that was, and is, used
only in parts of North Africa -- and thus in Moorish Spain, from
where the rest of Europe got them.

  - Eric
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

[John Ralls]

> On Apr 7, 2018, at 1:26 PM, Eric Siegerman  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 
>>>  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 Each of these behaves like "0":
>   abcd - Debit becomes blank (ie. zero)
> - Focus moves as appropriate for
>   
> 
>a5 as above
> 
>   5a   Nothing happens.  The Debit field
>   containing "5a" remains focused, even
>   after repeated s
> 
>   5a 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  or  out of
>  the Credit field, Debit returns to its
>  previous value
>- N.B.: This is unlike "abcd",
>  which sets Debit to zero
>  unconditionally
> 
> An e-acute it treated like "5a" above (even if I don't type any
> digits):
>abécdAs for "5a" (except that the cursor
>   jumps to just before the offending "é")
> 
>abécd  As for "5a"
> 
> 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  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

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel