10:37 a.m.
Hi,
I'm not sure if the following problem exists also in the current beta version
of the xemacs, but it exists at least in the version 21.4 (patch 8).
Bug (problem) description:
XEmacs 21.4 (patch 8)
SuSE Linux 8.1 with KDE 3.x
LANG=de_DE＠euro
When I select a string with german (Umlaute) characters (äöüÄÖÜß)
with the mouse in a xterm (or konqueror, mozilla, ...) and paste it
in the XEmacs, I'll get a string, which looks like ^[...iso8859-15^Bäöü,
which is very annoying.
Workaround:
I've written a workaround (look at the attached file)
to fix it. I know it's not the real fix for this problem, but it works for
me. Feel free, to put it in your distribution, if no one has fixed the real
problem in the next XEmacs version.
With best regards,
Heiko
PS: iso8859-15 is a new version of iso8859-1. I think most people in
europe use or will use these fonts at least caused by the euro
sign in these fonts.
PPS: It works in the GNU Emacs too.
--
Dr.-Ing. Heiko Muenkel
VisionConnect GmbH, Vahrenwalder Str. 7, 30165 Hannover
PGP Fingerprint: 18 EA 68 59 77 A8 30 97 EA 8C 2B 55 7C BA 8C F1
4:10 a.m.
>>>> "Heiko" == Heiko Muenkel <Dr.>
writes:
Heiko> When I select a string with german (Umlaute) characters
Heiko> (äöüÄÖÜß) with the mouse in a xterm (or konqueror, mozilla,
Heiko> ...) and paste it in the XEmacs, I'll get a string, which
Heiko> looks like ^[...iso8859-15^Bäöü, which is very annoying.
The apps are broken, and so is XFree86. That is an X Compound Text
Encoding extended segment, and use of those for members of the ISO
8859 family is specifically prohibited by the standard, as revised by
XFree86 as well as in the X.org original.
One of these days I'll add code to deal with this lunacy, but I don't
know if it will go into the 21.4 series or not.
--
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.
9:39 a.m.
Ar an 1ú lá de mí 5, scríobh Stephen J. Turnbull :
The apps are broken, and so is XFree86. That is an X Compound Text
Encoding extended segment, and use of those for members of the ISO
8859 family is specifically prohibited by the standard, as revised by
XFree86 as well as in the X.org original.
Just a heads-up; I've opened an XFree86 bug on that issue,
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=228 , and may
actually go do something useful about it myself.
--
"I have heard the swelling cry of the English speaking peoples of the
world, and it tells me their cause is served best by flaming the few
complacent asses on usenet." -- T. Samant, 29 June 1997
11:26 a.m.
This really should move to -design. Reply-To set.
>>>> "Aidan" == Aidan Kehoe
<kehoea(a)parhasard.net> writes:
Aidan> may actually go do something useful about it myself.
Cool!
As it turns out, it's easy to do in Lisp (except for the encoding name
canonicalization problem, which is a matter of collecting the
aliases), since (fortunately) XEmacs calls out to Lisp for this
function. (Which makes sense, as what's slow about selection
processing is waiting for X11 protocol round-trips.)
I don't object to implementing it, since it's an application (even if
illegal:-þ) of a necessary function. What bugs me is that the
proliferation of unnecessary standards (this incoherent use of the
extended segment where specifically prohibited; the whole Xutf8*
family of APIs[1]) which masks the utility of the _good_ ideas (like
the UTF8_STRING conversion target).
While we're at it, here's a proposal I made on emacs-devel for dealing
with limited-repertoire Unicode subsets. Handa-san (the main Emacs
Mule developer) seems to like it.
------------------------------------------------------------------------
From <87ist17vzu.fsf_-_(a)tleepslib.sk.tsukuba.ac.jp> on
...
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
PROBLEMS> * Characters from the mule-unicode charsets aren't
PROBLEMS> displayed under X.
PROBLEMS> XFree86 4 contains many fonts in iso10646-1 encoding
PROBLEMS> which have minimal character repertoires (whereas the
PROBLEMS> encoding is meant to be a reasonable indication of the
PROBLEMS> repertoire).
*sigh* "iso10646" is not meant to be an indication of repertoire.
See section 13 of the ISO 10646 standard. It's intended to fix the
ISO 8859 ambiguity. There is a deficiency in XFree86, but it's not
that the fonts are incomplete (note the word "implicit" in the XLFD
standard, that refers to current national encoding practice at
definition time, not to UCSes); that's gonna happen. Why should a
Russian font designer provide Thai glyphs? And what Thai in her right
mind would prefer those over native-designed fonts (without looking at
them)?
Instead, the font names and properties should provide encoding range
specifications instead of the useless "1" (which in ISO 10646-1 is not
an encoding specification, really). As a first take, I think a
reasonable way to do this would be to specify that for the iso10646
registry the encoding field of an XLFD name should contain a
comma-separated list of Unicode block names, or a comma-separated list
of hex ranges xxxx..yyyy (can't use hyphens for the ranges,
obviously). As long as the XLFD is otherwise fully-qualified (ie,
contains 14 hyphens), the block name format allows you to query with
"-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-*CYRILLIC*" and guarantee sane
results. Mostly "*-iso10646-*CYRILLIC*" should work OK, too. With
the hex range format, the app has to work harder, querying with
"-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-*" and checking for the ranges it
needs. IIRC, since the actual font loaded is known to the server, you
could even have multiple such aliases, one for each block, and with
languages using multiple blocks (basically, all of them, since
everybody uses ASCII), you'd just want to be careful to query for the
"rare" blocks first.
This would also allow Emacs and other smart apps to create virtual
fonts (ie, in faces) by requesting Ryumin Light for the Han and Kana
blocks and Times-Roman for the Basic Latin and Latin-1 Supplement
blocks, as an alternative to X Font Sets. (This would be nearly
trivial to implement in XEmacs since we use specifiers to implement
faces, and specifiers already do magic to connect charsets to font
registries. I suppose it would be more work in GNU Emacs, but I
haven't looked at Emacs's font set code.)
Does this look like something reasonable for Emacs (and XEmacs) to
implement on the client side? If so, I'll play with it a bit (note
that implementing this server-side is simply a matter of editing
fonts.aliases) and then put it in play with the X11 and XFree86
people.
------------------------------------------------------------------------
Footnotes:
[1] All that is needed is XmuCvtUTF8StringToExtendedSegment.
--
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.
9:32 a.m.
>>>> "Heiko" == Heiko Muenkel
<muenkel(a)tnt.uni-hannover.de> writes:
Heiko> I know it's not the real fix for this problem, but it works
Heiko> for me.
Except that it should trash all your EURO SIGNs, no? (If not, you may
be winning because of a default to ISO 8859-15 in your language
environment. Try under LANG=C xemacs -vanilla. If you still get
correct EURO SIGNs, I'll be very surprised.)
Heiko> PPS: It works in the GNU Emacs too.
? I thought GNU Emacs had installed a fix to be compatible with the
XFree86 breakage. Unfortunately, I doubt the improved fix below
(which is easily generalizable to KOI8, VISCII, ISCII, and Unicode in
such segments) works in GNU Emacs. The basic string manipulation
should work (so you might prefer to add it to your library, so you can
use it in both Emacsen), but I rather doubt that GNU Emacs provides
the same hooks.
Heiko> Feel free, to put it in your distribution, if no one has
Heiko> fixed the real problem in the next XEmacs version.
Could you try this? Works for me in light testing in 21.5.12 (but no
EURO SIGN, just the umlaute characters from your mail). If it works
for you too, I'll clean it up and add it to the latin-unity package
(with a proper installer/uninstaller, of course).
------------------------------------------------------------------------
(require 'latin-unity-latin9) ; I doubt you need this, can't hurt
(defconst sjt/extended-segment-parser-re
(concat "\033%/" ; extended segment escape
"[0-4]" ; if we grok it, we should know width
"\\([\200-\377][\200-\377]\\)" ; length specification, base 128
"\\([^\002]*\\)" ; TODO: should match only Latin 1
"\002") ; ASCII STX = START OF TEXT
"Regexp to detect and parse X Compound Text extended segment parameters.")
(defconst sjt/coding-system-x11-aliases
"Coding system aliases used in X Compound Text extended segments.
NB: we sanity check all uses of this mapping, so even if the particular
XEmacs doesn't know that coding system, please report as a bug if you see
a broken paste of the form \"^[%/1\200\227iso8859-15\002...\"."
;; TODO: add to this list.
'(("iso8859-15" . iso-8859-15)))
(defun sjt/find-coding-system-from-alias (name)
(setq name (downcase name))
(cond ((find-coding-system (intern name)))
((let ((pair (assoc name sjt/coding-system-x11-aliases)))
(when pair (find-coding-system (cdr pair)))))
;; we could try guessing here, eg a prefix "iso" -> "iso-"
(t nil)))
(defun sjt/select-convert-from-text (selection type value)
"Converts a text selection to a Lisp string, handling X11 extended segments."
(when (stringp value)
(catch 'unconvertible
(while (string-match sjt/extended-segment-parser-re value)
(let* ((cs (find-coding-system (sjt/find-coding-system-from-alias
(match-string 2 value))))
(segstart (match-end 0))
(lenspec (match-string 1 value))
(length (+ (* 128 (- (char-to-int (aref lenspec 0)) 128))
(- (char-to-int (aref lenspec 1))
128
(length (match-string 2))
1)))
(segend (+ segstart length)))
(unless cs (throw 'unconvertible nil))
(setq value (concat (substring value 0 (match-beginning 0))
(decode-coding-string
(substring value segstart segend)
cs)
;; should eliminate while in favor of
;; tail-recursion on this substring
(substring value segend))))))
value))
(defun sjt/toggle-compound-text-converter ()
"Toggle the recognition and conversion of compound text extended segments."
(interactive)
(when (emacs-version>= 21 4)
(let ((cvt (cond ((eq (cdr (assoc 'TEXT selection-converter-in-alist))
'select-convert-from-text)
'sjt/select-convert-from-text)
(t 'select-convert-from-text)))
(alist selection-converter-in-alist))
;; no mercy!!
(while alist
(when (memq (cdar alist)
'(select-convert-from-text sjt/select-convert-from-text))
(setcdr (car alist) cvt))
(setq alist (cdr alist)))
(message "%s" cvt))))
;; OK, do it!
(sjt/toggle-compound-text-converter)
------------------------------------------------------------------------
--
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.
7876
days inactive
7877
days old
4 comments
3 participants
participants (3)
-
Aidan Kehoe -
Heiko Münkel -
Stephen J. Turnbull