>>>> "Kyle" == Kyle Jones
Kyle> Anyone know enough about MULE to put in a iso-8859-15 coding
Kyle> system into 21.1.14? It would be useful for the European
Kyle> users of the stable code line to have this, given the
Kyle> adoption of the euro. Requests for it are starting to
Kyle> trickle into the VM lists.
Announcing availability of beta test version of the latin-unity
package for Mule XEmacs.
o ISO 8859/15 for XEmacs 21.4 (lightly tested) and 21.1 (untested).
To get 'iso-8859-15 preferred to 'iso-8859-1 in autodetection, use
(set-coding-category-system 'iso-8-1 'iso-8859-15). (untested)
If all you want is ISO 8859/15 support, you can either copy the
ISO 8859/15 setup to another file, or `(require 'latin-unity-vars).
o If a buffer contains only ASCII and ISO-8859 Latin characters, the
buffer can be "unified", that is treated so that all characters are
translated to one charset that includes them all. If the current
buffer coding system is not sufficient, the package will suggest
alternatives. It prefers ISO-8859 encodings, but also suggests
UTF-8 (if available; 21.4+ feature), ISO 2022 7-bit, or X Compound
Text if no ISO 8859 coding system is comprehensive enough.
It allows the user to use other coding systems, and the list of
suggested coding systems is Customizable.
This probably also is useful out of the box if the buffer contains
non-Latin characters in addition to a mixture of Latin
characters. For example, I believe it would reduce a buffer
originally ISO-2022-JP (including Latin-1 characters) to ISO
8859/1 if all the Japanese were deleted. (untested)
o Hooks into `write-region' to prevent (or at least drastically
reduce the probability of) introduction of ISO 2022 escape
sequences for "foreign" character sets. This hook is not set by
default in this package yet; try M-x latin-unity-test RET for a
short introduction and some useful C-x C-e'able exprs.
This may permit us to turn off support for those control sequences
entirely in our ISO 8859 coding-systems.
o Depends only on mule-base in operation. Table generation depends
on Unicode support such as Mule-UCS or Ben's ben-mule-21-5
workspace, and the package build currently requires Mule-UCS.
o If the buffer is changed by the hook, apparently write-region
starts over again from the top. The buffer is checked again, and
you are asked to choose the coding system again. If you choose
the same one, then the save goes through.
Note that if you choose a non-default coding system the first time
through, you will not get your choice as a default the second
time. You'll get the same default as the first time.
o Probable performance hit on large (> 20kB) buffers with many
(>20%) non-ASCII characters. Possible otimizations are given near
`latin-unity-region-feasible-representations' in latin-unity.el.
o Custom-loads aren't built for the package. You'll need to `(require
'latin-unity)' to get Customize's information loaded.
o Package depends on Mule-UCS.
Show-stopping, data-corrupting, home-wrecking bugs:
o None known.
o Fix the misfeatures.
o GNU Emacs support.
o Fix JIS Roman (as an alternative to ASCII) support.
o More UI features (like list of unrepresentable charsets, and
perhaps highlighting them in buffer)
o Integration to development tree (but probably not 21.4, this
package should be good enough).
o Eliminate all need for Mule-UCS.
o Extension to Han-unity. This needs to be treated more carefully.
Get the XEmacs/packages/mule-packages/latin-unity module. (A
module alias will be defined on general release.) You'll need to
fix up the lists of packages in the package-compile.el utility
(and possible in mule-package/Makefile) to build a package, but
just byte-compiling latin-unity and latin-unity-tables, and
putting them on your path should be fine.
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.