Re: [PATCH] Generalize start-process with keyword args

[Eli Zaretskii <eliz@gnu.org>]

> From: Daiki Ueno <ueno@gnu.org>
> Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>,  emacs-devel@gnu.org
> Date: Wed, 18 Mar 2015 15:17:39 +0900
> 
> > IMO, it will be terribly confusing to have incompatible treatment of
> > nil in this one API.
> 
> I tend to agree with Stefan, as I find no documentation about the
> implication of no-conversion for ":coding nil" except in the C source
> code.

Since you mentioned the documentation, you seem to interpret
"confusing" as in "confusing Lisp programmers".  But that's not what I
meant: I meant that this unfortunate convention will confuse Lisp
programs which call this API instead or together with the existing
APIs.  Despite what you might think, this convention _is_ used in
several places in Emacs sources; I've bumped into it in the past.  If
'make-process' wants to be compatible with existing interfaces, it
should use the same conventions.

For example, imagine some wrapper around 'make-process' that generates
the coding systems from some data, like MIME charset or something.
Such programs usually test the validity of the result by calling
coding-system-p (which returns t for nil), and if that returns OK, go
ahead and use the resulting coding system.  Imagine the confusion if
'make-process' rejects such values, or assigns its own semantics to
some of them.

I could support a thorough eradication of this convention from all
related interfaces.  But doing that for a single interface is not TRT,
IMO, as it will increase the memory pressure on the Lisp programmers,
which will now have to remember 2 different conventions about this,
and also which API supports which semantics of nil there.  Moreover,
if we ever want to replace 'start-process' with 'make-process' in some
it the users of the former, we will now have to remember to add code
that, when given nil, passes 'binary'.  That's worse than bad
conventions, IMO.