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

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Thu, 02 Apr 2020 13:10:37 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Now that Iʼve actually tested it, the change looks like this, making
    >> make-network-process and make-serial process behave the same as
    >> make-process and make-pipe-process. Iʼve looked at all uses of those
    >> two functions in Emacs' sources, and none of them depend on the change
    >> in semantics, in fact only a couple of them actually pass a :coding
    >> keyword.
    >> 
    >> Having said all that, this does go back a looooong way (2002 at
    >> least), so maybe we want to let sleeping dogs lie.

    Lars> Yeah, it does sound slightly scary, but I think the current nil
    Lars> behaviour for :coding is probably not something any code would rely
    Lars> on...  I'm not quite sure what `nil' semantics for :coding here would
    Lars> signify?

No code in Emacs that I could find relies on it. The new semantics
would be 'use coding-system-for-read', which I think is defensible.

    Lars> On the other hand, I generally think that functions should respect their
    Lars> parameters, so if you say :coding nil, it might then be somewhat
    Lars> surprising that `coding-system-for-{read,write}' are used instead?

    Lars> So I'm not quite sure that the current make-network-process behaviour
    Lars> here is a bug.

Itʼs different from make-process and make-pipe-process, itʼs
undocumented, and it was surprising to both me and Andreas. If it
turns out that in some obscure case somebody really needs the old
behaviour, then binding coding-system-for-{read,write} will still be
available, as will set-process-coding-sytem (or even passing :coding
'(nil nil), but thatʼs just evil :-) )

Robert