From xemacs-m  Thu Dec  5 19:38:30 1996
Received: from etlpost.etl.go.jp (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id TAA07933 for <xemacs-beta@xemacs.org>; Thu, 5 Dec 1996 19:38:27 -0600 (CST)
Received: from etlpom.etl.go.jp by etlpost.etl.go.jp (8.6.9+2.4W/2.7W)
	id KAA18914; Fri, 6 Dec 1996 10:38:23 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA21093; Fri, 6 Dec 96 10:38:21 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id KAA06318; Fri, 6 Dec 1996 10:39:25 +0900
Date: Fri, 6 Dec 1996 10:39:25 +0900
Message-Id: <199612060139.KAA06318@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mrt@mickey.ai.kyutech.ac.jp, mule@etl.go.jp, xemacs-beta@xemacs.org,
        brewin@Eng.Sun.COM, Teruhiko.Kurosaka@Japan.Sun.COM
In-Reply-To: <199612020640.WAA19812@xemacs.eng.sun.com> (message from Martin
	Buchholz on Sun, 1 Dec 1996 22:40:56 -0800)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Sun, 1 Dec 1996 22:40:56 -0800
   From: Martin Buchholz <mrb@Eng.Sun.COM>
   Murata> Now, I think coding-system-alist should be as follows:
   Murata> *Alist of elements
   Murata> (REGEXP OPERATION CODING-SYSTEM-FOR-READ [CODING-SYSTM-FOR-WRITE
   Murata> [CODING-SYSTEM-FOR-PROCESS-ARGUMENTS]]).
   Murata> ...

   This is an interesting proposal.  Some observations:

I posted a modified version to mule@etl.go.jp a while ago.  I'll
attach it at the tail again.  Please take a look at it.

   I would prefer to see separate alists for each of the different kinds
   of operations, if only for performance reasons - they are logically
   separate.  coding-system-for-process-arguments is only used with
   process operations.

I deleted it in the modified version because it is almost allways the
same as coding-system-for-write to encode for a process.

   For file operations, one would almost always want
   coding-system-for-write to match whatever was used when reading the
   file.  If coding-system-for-read and coding-system-for-write were
   different, then files would be saved in a different form after
   editing.

Sure.  So, I modified `write-region' so that if a buffer bounds
`buffer-file-coding-system' locally, it is prior to what set in
coding-system-alist in the not-yet-released version.

CODING-SYSTEM-FOR-WRITE for a specific file (e.g. *.txt, *.el) should
be used mainly when one write a new file.

   I'm not sure how useful coding-system-alist will be for process
   operations.  Typically I would like interactive shells to be run with
   coding-system-for-read and coding-system-for-write set to the
   `natural' coding-system for that OS, but it's hard to come up with a
   regexp that will match all possible names of shells.  I predict that
   having shell mode use a particular coding system will be best solved
   by using code run from shell-mode, e.g. in shell-mode-hook, as
   implemented in XEmacs 20.0.

How about registering `shell-file-name' in coding-system-alist?
Anyway, that `natural' setting for OS usually doesn't consider
multilingual environment, just a localization.  I hate it.  I don't
want to see the output of `date' in Japanese, but I do want to see
Japanese/Chinese/Thai/... text if it is there when, for instance, I
invoke `head FILENAME'.

   The most recent XEmacs 20.0 has a variable `pathname-coding-system'
   and that is used to decode the filename of file operations and the
   arguments of process operations (including the xemacs process itself).
   It is not obvious how mule handles file and directory names encoded in
   some coding system (typically the one supported by the OS,
   e.g. euc-japan on Solaris 2) - is this capability not implemented, or
   am I missing something?

Mule 2.3 also has `pathname-coding-system', but RMS refused the way it
is implemented.  So, mule-19.33-delta doesn't have the feature.  We
agreed to discuss it lator.

---
Ken'ichi HANDA
handa@etl.go.jp

------------------------------------------------------------
Return-Path: <handa@etl.go.jp>
Reply-To: mule@etl.go.jp
Errors-To: handa@etl.go.jp
Sender: handa@etl.go.jp
X-Seqno: 1914
Date: Wed, 6 Nov 1996 11:40:30 +0900
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Subject: coding-system-alist
Content-Type: text
Content-Length: 3803

As for the specs of coding-system-alist, set-coding-system-alist,
find-coding-system, I'm now considering the following spec.  This
change is because the current version (delta) can't give sufficient
information to a fucntion (which is registered in coding-system-alist)
to decide correct coding systems.

In each I/O primitive functions (e.g. Finsert_file_contents ()),
Ffind_coding_system is called to decide a coding system to be used for
code conversion.

I have eliminated a facility to specify a coding system to encode
process argument because, as far as I know, it can be the same as the
coding system to encode text of the region given to the process.

Could you please check these specs whether I miss something important
or not?

---
Ken'ichi HANDA
handa@etl.go.jp


---------- coding-system-alist ------------------------------

Documentation:
Nested alist to decide a coding system for a specific I/O operation.
The format is ((OPERATION . ((REGEXP . CODING-SYSTEMS) ...)) ...).

OPERATION is one of the following Emacs I/O primitives:
  For file I/O, insert-file-contents and write-region.
  For process I/O, call-process, call-process-region, and start-process.
  For network I/O, open-network-stream.

REGEXP is a regular expression matching a target of OPERATION, where
target is a file name for file I/O operations, a process name for
process I/O operations, or a service name for network I/O
operations.  REGEXP might be a port number for network I/O operation.

CODING-SYSTEMS is a cons of coding systems to encode and decode
character code on OPERATION, or a function symbol returning the cons.
See the documetation of `find-coding-system' for more detail.

---------- find-coding-system: a built-in function. --------------------

Return a cons of coding systems for I/O primitive OPERATION.
Remaining arguemnts are for OPERATION.

OPERATION is one of the following Emacs I/O primitives:
  For file I/O, insert-file-contents or write-region.
  For process I/O, call-process, call-process-region, or start-process.
  For network I/O, open-network-stream.
For each OPERATION, TARGET is selected from the arguments as below:
  For file I/O, TARGET is a file name.
  For process I/O, TARGET is a process name.
  For network I/O, TARGET is a service name or a port number

The return value is a cons of coding systems for decoding and encoding
registered in nested alist `coding-system-alist' (which see) at a slot
corresponding to OPERATION and TARGET.
If a function symbol is at the slot, return a result of the function call.
The function is called with one argument, a list of all of the arguments.

---------- set-coding-system-alist: a Lisp function. --------------------
(set-coding-system-alist TARGET-TYPE REGEXP CODING-SYSTEM &optional OPERATION)

Update `coding-system-alist' according to the arguments.
REGEXP is a regular expression matching a target of I/O operation.
TARGET-TYPE specifies a type of the target: `file', `process', or `network'.
  TARGET-TYPE tells which slots of coding-system-alist should be affected.
  If `file', it affects slots for insert-file-contents and write-region.
  If `process', it affects slots for call-process, call-process-region, and
    start-process.
  If `network', it affects a slot for open-network-processs.
CODING-SYSTEM is a coding system to perform code conversion
 on the I/O operation, or a cons of coding systems for decoding and
 encoding respectively, or a function symbol which returns the cons.
Optional arg OPERATION if non-nil specifies directly one of slots above,
  Emacs I/O primitives: insert-file-contents, write-region,
  call-process, call-process-region, start-process, and open-network-stream.
If OPERATION is specified, TARGET-TYPE is ignored.
See the documentation of `coding-system-alist' for more detail.


