[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51733: 27.1; Detect impossible email addresses better
From: |
Eli Zaretskii |
Subject: |
bug#51733: 27.1; Detect impossible email addresses better |
Date: |
Mon, 17 Jan 2022 19:48:01 +0200 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 51733@debbugs.gnu.org, jidanni@jidanni.org
> Date: Mon, 17 Jan 2022 18:38:48 +0100
>
> I'm looking at the Confusable section now.
>
> https://www.unicode.org/reports/tr39/#Confusable_Detection
>
> Looks easy enough to implement (and the ELPA package already does the
> parsing, so I'll be reusing bits from that).
>
> But... I'm wondering what the higher level interface would be? I mean,
> quite a lot of strings are confusable with something else, but which
> ones are interesting? The only thing that seems immediately interesting
> to check for is whether a string is confusable with ASCII?
>
> That is,
>
> (textsec-confusable-with-ascii-p "CπππΌπ
πΎ")
> => t
>
> Because the ASCII characters are the ones that people rely on when doing
> ... things, like email and browsing the web.
>
> But I mean, "CπππΌπ
πΎ" is confusable with "Π‘ΡΠ³ΡΣΠ΅" (the latter is
> Cyrillic), and if you're writing Russian, that might also be
> interesting. So perhaps a
>
> (textsec-confusable-with-script-p "CπππΌπ
πΎ" 'cyrillic)
> => t
>
> ? But... I'm not sure in which contexts that would actually be vital
> to know. Hm.
I think we should first determine what kinds of applications may need
this, and take it from there. The initial number of "confusability
with" classes can be very small, and we can add more as we discover
interesting use cases. The full number is pretty much infinite, I
think, but I'm not sure Emacs needs to support all of them OOTB. We
could support some of the popular ones, and provide infrastructure for
developing more.
- bug#51733: 27.1; Detect impossible email addresses better, (continued)
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/16
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/16
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better,
Eli Zaretskii <=
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/17
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Lars Ingebrigtsen, 2022/01/18
- bug#51733: 27.1; Detect impossible email addresses better, Eli Zaretskii, 2022/01/18