[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs-diffs Digest, Vol 2, Issue 28
From: |
Kenichi Handa |
Subject: |
Re: Emacs-diffs Digest, Vol 2, Issue 28 |
Date: |
Tue, 28 Jan 2003 09:32:54 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
In article <address@hidden>, Richard Stallman <address@hidden> writes:
> [...]
> * process.c (read_process_output): Decide the multibyteness of
> string given to a process filter by a coding system used for
> decoding the process output.
> But, I don't remeber the detail now.
> set-process-multibyte should be a good solution.
I think we have extrapolated the behaviour of process I/O
from that of file I/O. But set-process-multibyte breaks it.
It's something like declaring the multibyteness of a process
but we don't declare that of a file. So it's not easy to
extrapolate the exact semantics of set-process-multibyte.
It is fairly clear for the case that a process has a fileter
and coding system is no-conversion or raw-text. But what to
do with the other coding systems (e.g. Latin-1,
iso-2022-jp). If a process is unibyte, what kind of string,
the filter should get? Should we suppress a text decoding
like the case of inserting a file into a unibyte buffer?
And if the process has no filter but has a buffer, what to
do for a unibyte process that has a multibyte buffer, or for
a multibyte process that has a unibyte buffer?
And what to do with process-send-string/region.
I think it is better to keep extrapolating the behaviour of
process reading/sending from file reading/writing.
For inserting a proecss output in a buffer, there's no
difficulty to extrapolate the behaviour.
For a filter, although we don't have a function something
like string-from-file, the most resembling code will be
this.
(with-temp-buffer
(insert-file-contents FILE)
(buffer-string))
A string given to a process filter must be the same as the
result of that code, which means that
default-enable-multibyte-characters decides the
multibyteness, and if it is nil, character conversion except
for end-of-line conversion is suppressed.
The only question is when to check
default-enable-multibyte-characters. When a process is
created, or just before calling a filter? I think the
former is more like file I/O. And it may be ok to have a
function set-process-filter-multibyte which can change the
multibyteness of a string to a filter on the way.
Or, was the intention of set-process-multibyte actually
set-process-filter-multibyte?
---
Ken'ichi HANDA
address@hidden
- Re: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28], (continued)
- Re: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28], Richard Stallman, 2003/01/22
- Re: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28], Eli Zaretskii, 2003/01/21
- Re: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28], Kenichi Handa, 2003/01/21
- Re: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28], Richard Stallman, 2003/01/22
- Re: unibyte<->multibyte conversion [Re: Emacs-diffs Digest, Vol 2, Issue 28], Stefan Monnier, 2003/01/22
Re: Emacs-diffs Digest, Vol 2, Issue 28, Kenichi Handa, 2003/01/19
Re: Emacs-diffs Digest, Vol 2, Issue 28, Richard Stallman, 2003/01/21