GNU bug report logs - #71080
30.0.50; UTF-8 used unconditionally when saving GPG file

Previous Next

Full log

Message #11 received at 71080 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71080 <at> debbugs.gnu.org
Subject: Re: bug#71080: 30.0.50; UTF-8 used unconditionally when saving GPG
 file
Date: Mon, 20 May 2024 12:38:50 -0400

> How can this work reliably, unless the *.gpg files can have some
> meta-data that tells Emacs how to decode them?

GPG takes bytes in and split bytes out, so there's no encoding
issue there.  The contents in my example very much comes with the needed
meta-data (in the form of a `coding` file-local var).  That meta-data is
correctly used when opening the file (which is why the UTF-8 byte sequence
is not turned into `λ` but is kept as `eight-bit` chars) but not when saving.

> When encoding, we could perhaps use buffer-file-coding-system (AFAICT,
> we do that indirectly now, via select-safe-coding-system), but what to
> do when decoding?

As mentioned, AFAICT we DTRT already when decoding (at least when the
coding system is specified via a file-local var).  The problem is when
saving: `select-safe-coding-system` ends up returning `no-conversion`
despite the `coding:` cookie.

> If _you_ know the correct encoding, you could use "C-x RET c" before
> the commands (as in "C-x RET c iso-2022-7bit RET C-x C-w").  Did you
> try that?

I tried `C-x RET f`.  It makes no difference.  And it should not be
needed since the file-local var states very explicitly what we
should use.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.