bug#71080: 30.0.50; UTF-8 used unconditionally when saving GPG file

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 71080@debbugs.gnu.org
> 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.

Yes, but what bytes?  You can encode a buffer using UTF-8 or you can
encode it using ISO 2022, and in each case you will get a different
bytestream.  GPG doesn't care either way, but the bytes it will get
and encode will be different.

> 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.

Any evidence for that?  Can you take me through the code to show that
buffer's encoding is ignored?  What I see there is that we choose a
reasonable encoding when sending data to GPG, but maybe I'm not
looking in the right place.

> > 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.

Please tell where in the code you see that.

AFAIK, the coding cookie is supposed to determine
buffer-file-coding-system, and select-safe-coding-system tries
buffer-file-coding-system as part of the values it attempts to use.

> > 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.

Not "C-x RET f", but "C-x RET c".

> And it should not be needed since the file-local var states very
> explicitly what we should use.

Yes, but "C-x RET c" is generally stronger, so if it helps, it's a
sign that the code is correct, but uses incorrect defaults.  That's
why I suggested to try it.  However, if you know the code and can tell
how and where we determine which encoding to use, that'd be more
efficient.

Thanks.