Eli Zaretskii <
address@hidden> schrieb am Mi., 4. Apr. 2018 um 15:39 Uhr:
> From: Philipp Stephani <address@hidden>
> Date: Wed, 4 Apr 2018 14:02:18 +0200
> Cc: Philipp Stephani <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.
> + (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?
> + (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.