Unicode security-issues workarounds elsewhere [Was: Re: Change of Lisp syntax for "fancy" quotes in Emacs 27?]

[Garreau\, Alexandre]

Le 06/10/2018 à 14h50, Eli Zaretskii a écrit :
>> From: "Garreau\, Alexandre" <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>, address@hidden,
>> address@hidden, address@hidden
>> Date: Sat, 06 Oct 2018 13:22:14 +0200
>> 
>> In a world where unicode is increasingly present and confusion about its
>> characters increasingly problematic (typosquatting, etc.) wouldn’t it be
>> reasonable to expect unicode-related semantic functions to be provided
>> in most frameworks, systems and languages to allow better handling of
>> such problems, thus making that problem the interface’s one?
>
> I don't think I understand what this means in practice; please
> elaborate.

The point I wanted to make is since as I highlighted this problem is of
greater importance in other interfaces than source codes, especially
browsers and web sites, typically, as these gets to be the most used
interfaces for everything nowadays.  So I guess these unicode
anti-confusion functions and more high-level functions based on these
already are or will become present in browsers and in languages such as
perl and php to end up in high-level functions in frameworks made in
perl or php, for instance, so that at the end “other interfaces than
emacs” such as web-browsers or websites may end supporting features such
as coloring differently mixed-script or unusual spaces, etc.

The other option being “ban unicode as much as possible” or “disallow
mixed-script”, and “ban all unicode punctuation characters (or all
non-letters (or non-alphanumeric?) characters, or something like that)
unless they’re inside ascii”.

I believe with increased support of unicode most languages, frameworks
and software should end with features allowing to allow these without
creating too much problems (at least not that much a lot more than in
emacs).