On Wed, Sep 21, 2005 at 04:32:06PM -0700, Anton Zinoviev wrote:
> Changes:
> bgoffice (3.0-5) unstable; urgency=low
...
> * Files /etc/emacs21/site-start.d/90{aspell-bg,ibulgarian}.el to
> codepage-setup cp1251. It is still not clear to me how to support
> spelling of Bulgarian UTF-8 texts in Emacs.
This should be internally handled by most {x}emacs if
buffer-file-coding-system is set to the encoding instead to 'undecided' or
equivalent. Notably xemacs21-nomule does not support that. ispell.el will
recode that UTF-8 to the encoding declared by the dictionary when sending
strings and the other way back when receiving them. That should be
transparent to the user, unless the original UTF-8 has characters that
cannot be recoded to the single byte encoding, leading to misalignment
errors (like in #205516).
> * Add entries for different Emacs versions in ibulgarian.info-ispell and
> aspell-bg.info-aspell. Thanks to Ivan Raikov, closes: #321040.
Seems that xemacs21 also does not support cp1251. The summary seems to be
emacs20: nothing
emacs21: cp1251
emacs22: cp1251, windows-1251
xemacs21: windows-1251
I would forget emacs20, that was not even shipped with sarge (and whose
iso-8859-1 entry was wrong), and concentrate in leaving only the cp1251
entry, that also matches aspell. The only problem is (emacs20 discarded)
with xemacs21, and seems to be easily fixable defining cp1251 as an alias to
windows-1251 for xemacs. I can add that in an initialization file.
I have seen another problem in the ispell entry name. While all utf-8
entries I tried displayed as raw chars in my latin1 environment when used
in a debconf prompt, showing all chars, the bulgarian entry seems to only
show the first char (as a 3 byte UTF-8 char) and nothing of the remaining
chars.
I do not have a clear position regarding this last, when the use of utf8
was introduced in policy seemed that all utf8 chars were to be displayed as
multibyte chains in single byte encodings, leaving in the worst case the
english translation readable. But this case confuses me, we should probably
suggest trying first some sort of 7bit 'native' transliteration when possible
instead of directly suggesting the use of UTF8, or at least using something
like
7bit_transliteration [UTF-8_native_name] (english translation)
when utf8 is used. I hope that would at least make the 7bit_transliteration
readable in the worst case, when something in the utf8 string confuses
whiptail (but I did not check that). This seems to not affect readline or
gnome frontends. Another possibility would be to leave things as they
currently are, expecting utf8 support be improved in the meantime.
What do you think?
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
