Re: Relaxing the restrictions for store item names

[Eidvilas Markevičius]

I guess that's true, but I very much doubt errors like this would come
up very often. Out of precaution, we could make guix lint issue us a
warning whenever a non-ASCII character is detected in a package name
or elsewhere. This would lower the chances of such oversights
occurring even more.

On Thu, Aug 24, 2023 at 7:30 PM Kaelyn <kaelyn.alexi@protonmail.com> wrote:
>
> Hi,
>
> On Tuesday, August 22nd, 2023 at 6:49 AM, Eidvilas Markevičius
> <markeviciuseidvilas@gmail.com> wrote:
>
> > Therefore, my proposal is to relax these limitations as much as
> > possible (or at least somewhat) and to allow some more freedom when it
> > comes to naming packages and other kinds of items in the store. We
> > could, of course, still disallow all the main problematic characters,
> > such as NUL, /, $, ~, space, newline and a few others, but other than
> > that, I don't see any reason to forbid any of the remaining ones from
> > being used.
>
> While I don't really have an opinion on the matter aside from the biases
> of growing up in the US, one non-trivial issue with Unicode store paths
> and package names which hasn't been mentioned is that of Unicode
> equivalence[1], particularly homographs[2]. For example U+0061 and U+0430
> (the Latin and Cyrillic small letter "a", respectively) are often visually
> identical but programmatically distinct. If not handled well, it could
> lead to untypable package or store names by virtue of the user having to
> guess which Unicode code point(s) is/are the correct one(s) for a certain
> visual glyph.
>
> Cheers,
> Kaelyn
>
> [1] https://en.wikipedia.org/wiki/Unicode_equivalence
> [2] https://en.wikipedia.org/wiki/IDN_homograph_attack