Re: [PATCH 3/3] Inherit process output coding system to stderr process.

[Eli Zaretskii]

> From: Philipp Stephani <address@hidden>
> Date: Sat, 07 Apr 2018 21:12:10 +0000
> Cc: address@hidden, address@hidden
> 
>  > * src/process.c (Fmake_process): Inherit output coding system to
>  > newly-created pipe process.
> 
>  I'm sorry, I don't understand the need for this "inheriting".  If the
>  problem is that make-process and make-pipe-process use different logic
>  to decide on the default coding-systems, then I think we should make
>  them use the same logic, and then there will be no need for
>  "inheriting".  Or is there something else I'm missing?
> 
> At least I would expect Emacs to use the same output encoding for both 
> standard output and error streams if
> an explicit output encoding is provided, given that most external programs 
> will also use the same encoding for
> both streams. But currently Emacs uses the default encoding for the standard 
> error stream if it creates the
> pipe itself.

But that's easy to fix: just pass the same :coding argument with which
make-process was invoked to Fmake_pipe_process.  (And make the code
which determines the encoding in both functions be identical while at
that.)

>  > +        (let ((process (make-process
>  > +                        :name "stderr-coding"
>  > +                        :command (list shell-file-name 
> shell-command-switch
>  > +                                       (concat "echo -e '\\xC3\\xA4\\r'; "
>  > +                                               "echo -e '\\xC3\\xB6\\r' 
> >&2"))
> 
>  This shell command is non-portable.  I think even "echo -e" is not
>  portable enough, let alone with hex escapes and the trailing \r.
>  Can't we use Emacs instead?  There's also the ";" issue again.
> 
> Is it possible to write raw bytes to the standard output/error streams using 
> Emacs?

Yes, use raw-text or no-conversion as the encoding (the former allows
to produce DOS and Mac EOLs, the latter doesn't).

>  > +          (should (equal (buffer-string) "\u00C3\u00B6\n"))))
>  > +      (should (equal (buffer-string) "\u00C3\u00A4\n")))))
> 
>  Why not use literal characters here?  It will make the source more
>  readable, IMO.
> 
> I don't care much, but using the character escapes here makes it obvious that 
> the output is decoded as
> Latin-1. 

On the contrary, it might miss that if the output is decoded as raw
bytes.  Using the actual characters, OTOH, will make sure that, I
think.