Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

[Robert Pluim]

>>>>> On Sat, 15 Oct 2022 07:01:02 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
    Eli>  	 (process-environment (eshell-environment-variables))
    Eli> +         (coding-system-for-read coding-system-for-read)
    Eli> +         (coding-system-for-write coding-system-for-write)

Isnʼt passing `:coding' to `make-process' preferred to binding
`coding-system-for-{read,write}'? It has less of a global effect.

Robert
-- 

Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 17 Oct 2022 16:42:35 +0200
> 
> >>>>> On Sat, 15 Oct 2022 07:01:02 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
>     Eli>  	 (process-environment (eshell-environment-variables))
>     Eli> +         (coding-system-for-read coding-system-for-read)
>     Eli> +         (coding-system-for-write coding-system-for-write)
> 
> Isnʼt passing `:coding' to `make-process' preferred to binding
> `coding-system-for-{read,write}'? It has less of a global effect.

But I _want_ a more global effect here.

Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

[Robert Pluim]

>>>>> On Mon, 17 Oct 2022 18:01:57 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>
    >> Date: Mon, 17 Oct 2022 16:42:35 +0200
    >> 
    >> >>>>> On Sat, 15 Oct 2022 07:01:02 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
    Eli> (process-environment (eshell-environment-variables))
    Eli> +         (coding-system-for-read coding-system-for-read)
    Eli> +         (coding-system-for-write coding-system-for-write)
    >> 
    >> Isnʼt passing `:coding' to `make-process' preferred to binding
    >> `coding-system-for-{read,write}'? It has less of a global effect.

    Eli> But I _want_ a more global effect here.

You do? I thought the whole point was to influence the coding system
used by `make-process', which you can do by passing in :coding.

Robert
-- 

Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 17 Oct 2022 17:11:07 +0200
> 
> >>>>> On Mon, 17 Oct 2022 18:01:57 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: Eli Zaretskii <eliz@gnu.org>
>     >> Date: Mon, 17 Oct 2022 16:42:35 +0200
>     >> 
>     >> >>>>> On Sat, 15 Oct 2022 07:01:02 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
>     Eli> (process-environment (eshell-environment-variables))
>     Eli> +         (coding-system-for-read coding-system-for-read)
>     Eli> +         (coding-system-for-write coding-system-for-write)
>     >> 
>     >> Isnʼt passing `:coding' to `make-process' preferred to binding
>     >> `coding-system-for-{read,write}'? It has less of a global effect.
> 
>     Eli> But I _want_ a more global effect here.
> 
> You do? I thought the whole point was to influence the coding system
> used by `make-process', which you can do by passing in :coding.

The case for using :coding here is quite weak:

  . the let-binding in this case is restricted to creation of the
    processes, so here it doesn't have more "global" effect that
    :coding
  . there are two processes being created, not one; let-binding
    affects both of them, whereas :coding would have to be applied to
    each one separately
  . :coding overrides coding-system-for-read/write, which is somewhat
    surprising and perhaps unexpected; while we could have code that
    sets :coding only if coding-system-for-read/write are nil, it
    would be a trickier code, and perhaps not self-explanatory without
    a suitable commentary

Now let me turn the table and ask you why is :coding preferred, in
your opinion?

Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

[Robert Pluim]

>>>>> On Mon, 17 Oct 2022 18:40:32 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli>   . the let-binding in this case is restricted to creation of the
    Eli>     processes, so here it doesn't have more "global" effect that
    Eli>     :coding
    Eli>   . there are two processes being created, not one; let-binding
    Eli>     affects both of them, whereas :coding would have to be applied to
    Eli>     each one separately
    Eli>   . :coding overrides coding-system-for-read/write, which is somewhat
    Eli>     surprising and perhaps unexpected; while we could have code that
    Eli>     sets :coding only if coding-system-for-read/write are nil, it
    Eli>     would be a trickier code, and perhaps not self-explanatory without
    Eli>     a suitable commentary

    Eli> Now let me turn the table and ask you why is :coding preferred, in
    Eli> your opinion?

Because weʼve had bugs where coding-system-for-read/write was used,
and processes created further down the call chain would use it, and by
the time they did its value had changed, which would have been avoided
by using :coding (I seem to remember an issue with an invocation of
gpg, although I wouldnʼt be surprised if there was some asynchronicity
involved as well)

Robert
-- 

Re: master 63d084d4e4: Fix encoding and decoding of process I/O in Eshell on Windows

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 17 Oct 2022 18:05:20 +0200
> 
>     Eli> Now let me turn the table and ask you why is :coding preferred, in
>     Eli> your opinion?
> 
> Because weʼve had bugs where coding-system-for-read/write was used,
> and processes created further down the call chain would use it, and by
> the time they did its value had changed, which would have been avoided
> by using :coding (I seem to remember an issue with an invocation of
> gpg, although I wouldnʼt be surprised if there was some asynchronicity
> involved as well)

But that's in no way a general preference, just a practical
consideration.  And the kind of problems you mention don't exist in
this case.