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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

Of what exactly?

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

I think my recipe is pretty clear: we start with

    λ
    # Local Variables:
    # coding: iso-2022-7bit
    # End:

and after save and `revert-buffer` we end up with

    \316\273
    # Local Variables:
    # coding: iso-2022-7bit
    # End:

\316\273 is the encoding of λ in UTF-8, not in `iso-2022-7bit`, so it
seems pretty clear that Emacs encoded the buffer using (some version of)
utf-8, thus disregarding the `coding:` cookie.

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

Try and reproduce my recipe after doing
`M-x trace-function RET select-safe-coding-system`.

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

AFAICT this gets overridden by the return value of `find-auto-coding` we
setup for `.gpg` files.

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

I haven't tried that, no.

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

I stepped through `select-safe-coding-system`, which is where I got the
info I described about `find-auto-coding` and
`find-coding-systems-region`.


        Stefan