[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus
From: |
Robert Pluim |
Subject: |
Re: bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus |
Date: |
Thu, 02 Apr 2020 14:48:05 +0200 |
>>>>> On Thu, 02 Apr 2020 13:10:37 +0200, Lars Ingebrigtsen <address@hidden>
>>>>> said:
Lars> Robert Pluim <address@hidden> 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