[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus

From: Eli Zaretskii
Subject: bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus
Date: Mon, 30 Mar 2020 16:10:15 +0300

> From: Robert Pluim <address@hidden>
> Cc: Lars Ingebrigtsen <address@hidden>,  address@hidden,
>   address@hidden
> Date: Mon, 30 Mar 2020 11:37:25 +0200
>     Eli> If that non-ASCII data is compatible with the default encoding, or if
>     Eli> Emacs will detect the encoding correctly given 'undecided', that
>     Eli> shouldn't be any problem.  And this function is only about getting 
> the
>     Eli> gpg configuration, so what kind of non-ASCII data is expected there?
>     Eli> And how would using 'no-conversion' here help?
>     Eli> If you can find those cases where you saw non-ASCII data in this 
> case,
>     Eli> by all means describe them or point to relevant discussions.
> My (admittedly fallible) memory is that gpg always uses UTF-8 for
> non-ASCII data (except for some old versions that %-escape it instead).

Is that true even on MS-Windows?  can someone please verify that?  If
gpg uses UTF-8 on all platforms, the 'undecided' isn't TRT, as in some
cases Emacs could mistakenly decide the encoding is the current system
codepage.  We should use 'utf-8' instead if UTF-8 is guaranteed.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]