Re: Emacspeak and UTF-8 -- possible?

[Raman]

>
>
> PS: How ironic that Emacspeak provides "the first really functional
>     interface on Linux for [blind and] VI users".

;-) It actually was a first in  helping  blind users run VI
independently on a
  workstation console --- thanks to the wonders of eterm.el in
  Emacs 19.26 --- which for the first time made curses-based apps
  runnable in an Emacs Term.

As for the character coding issues --- I forcibly set
EMACS_UNIBYTE to T in the Emacspeak setup files  a few years ago
to make it clear that the UTF-8 piece needed work. Doing anything
else would just cause bizarre/rude surprizes half-way while one
is working.

Now, when you have a system like Emacs itself which attracts a
large number of developers, it is possible to enable something as
complex as character encoding and translation and over time debug
all of the issues --- we've seen this happen in the case of
mainline Emacs over the last 8 years. However, Emacspeak does not
have this luxury, and pretending that multibyte support works
when it doesn't would only lead to large amounts of frustration
and support questions of the form "why doesnt xxx ." on the
mailing list.

For the record, it should be possible to now add multibyte
support by carefully binding buffer-encoding in the scratch
buffer used to transform text and by setting process-encoding for
that buffer before streaming out the text to the TTS process. But
doing this will require:

A)    Manpower Cycles(ramanpower cycles are vanishingly small for
this)
B)      Ability to test --- TTS engines, multibyte texts, and
        someone who uses it
C)      Early users who are sufficiently knowledgeable to be able
        to bear the pain, identify problems, and and define
        solutions

--Raman