Re: encode-coding diagnostics?

>>>>> "Ilya" == Ilya N Golubev <[email protected]> writes:

    Ilya> Versions: all known, including 21.4.

Cf latin-unity, which fixes a similar problem, and the code should be
applicable.  For a first try, use `charsets-in-region' (I don't think
there is a `charsets-in-buffer' function).  You might want to rewrite
in C; charsets-in-region is very slow, at least in an XEmacs with
error-checking enabled.  This gives a list of charsets, which you then
compare with the charsets that are "desirable" to encode for each
encoding.

You could also use the somewhat more efficient approach I used in
latin-unity, if exactly which alternative coding-system is preferred
depends on the set of characters in the buffer.  It's unlikely that I
would accept "safe-charsets" patches that change the behavior of
latin-unity.  But you could clone the hook function there and use the
support functions, including the table-building function in
latin-unity-utils.el, and the facility could be added as a package.

This stupid design of the coding systems goes all the way back to the
original Mule, where it didn't really matter because the Japanese use
full ISO 2022 coding systems which can handle all characters.  We're
working on it but it will take time, as Ben is currently having a real
life, and I currently have no time for working on hard stuff.  It
probably won't get fixed in 21.4.

It's likely that it has been fixed in GNU Emacs by using
"safe-charsets", but it's not possible to port their "safe-charsets"
support as the internals are very different (and it's a stupid idea in
the first place).

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.