[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Generalize start-process with keyword args
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH] Generalize start-process with keyword args |
Date: |
Wed, 18 Mar 2015 18:23:25 +0200 |
> From: Daiki Ueno <address@hidden>
> Cc: Stefan Monnier <address@hidden>, address@hidden
> 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.
- Re: [PATCH] Generalize start-process with keyword args, (continued)
- Re: [PATCH] Generalize start-process with keyword args, Stefan Monnier, 2015/03/17
- Re: [PATCH] Generalize start-process with keyword args, Eli Zaretskii, 2015/03/17
- Re: [PATCH] Generalize start-process with keyword args, Daiki Ueno, 2015/03/18
- [PATCH] Add facility to collect stderr of async subprocess, Daiki Ueno, 2015/03/18
- Re: [PATCH] Add facility to collect stderr of async subprocess, Eli Zaretskii, 2015/03/18
- Re: [PATCH] Generalize start-process with keyword args, Stefan Monnier, 2015/03/18
- Re: [PATCH] Generalize start-process with keyword args, Eli Zaretskii, 2015/03/18
- Re: [PATCH] Generalize start-process with keyword args, Daiki Ueno, 2015/03/19
- Re: [PATCH] Generalize start-process with keyword args, Stefan Monnier, 2015/03/19
- Re: [PATCH] Generalize start-process with keyword args, Daiki Ueno, 2015/03/23
- Re: [PATCH] Generalize start-process with keyword args,
Eli Zaretskii <=
- Re: [PATCH] Generalize start-process with keyword args, Stefan Monnier, 2015/03/18
- Re: [PATCH] Generalize start-process with keyword args, Eli Zaretskii, 2015/03/18
- Re: [PATCH] Generalize start-process with keyword args, Eli Zaretskii, 2015/03/17
- Re: Generalize start-process with keyword args, Andy Moreton, 2015/03/16
- Re: Generalize start-process with keyword args, Eli Zaretskii, 2015/03/16
- Re: Generalize start-process with keyword args, Andy Moreton, 2015/03/16
- Re: Generalize start-process with keyword args, Stefan Monnier, 2015/03/16
- Re: Generalize start-process with keyword args, Eli Zaretskii, 2015/03/17
- Re: Generalize start-process with keyword args, Andy Moreton, 2015/03/17
- Re: Generalize start-process with keyword args, Eli Zaretskii, 2015/03/17