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 > > account names > > account codes > > securities
> Filtering for meaning is Way Too Hard. It would be too hard just in English, > every additional localization squares it. > > Besides, if a user wants to have an emoji as (part of) an account name, isn’t > that the user’s business? It’s all Unicode, so from a text processing > standpoint no different from Chinese. What @John says makes sense to me. One can conceive of someone coming up with an "SFW" subset of Unicode for a given locale (assuming there's tooling to support Unicode subsets), and of GNC honouring that subset if requested -- but devising it doesn't seem like GNC's job. However... > > and offers them in places it shouldn't > > e.g. > > dates > > numbers Could you explain "offers" (as opposed to "allows")? I've been looking, and don't see them coming up in dropdown lists or the like. And when I try to type one directly into a numeric field (e.g. Debit), it's ignored completely. (That's in the register, on Linux, though; Windows or Mac OS might be different, as might different areas of GNC.) If emojis were being offered and/or accepted in a numeric field, though, shouldn't they be rejected as syntactically invalid? In this case, what they are is beside the point; it's what they *aren't*, i.e. numeric, that matters. - Eric _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
