GNU bug report logs -
#71080
30.0.50; UTF-8 used unconditionally when saving GPG file
Previous Next
Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Mon, 20 May 2024 15:44:02 UTC
Severity: normal
Found in version 30.0.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 71080 <at> 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.
This bug report was last modified 1 year and 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.