Ar an chéad lá is fiche de mí Meitheamh, scríobh Stephen J. Turnbull:
> >>>>> "Aidan" == Aidan Kehoe <kehoea(a)parhasard.net> writes:
> Aidan> The test case I gave didn’t involve Gnus, just
> Aidan> latin-unity, which is why I asked you in particular.
> Ah, sorry! What's even more sorry is I can't reproduce. :-( At least
> if I understand you correctly; the designed result is to end up with a
> buffer containing a bunch of ISO 646-IRV characters, with U+00F6,
> U+0192, and U+5357 mixed in, and the form returns nil, right? That's
> what I get.
Well, that’s encouraging, it works for someone :-) .
> Japanese language environment (probably not directly relevant).
> Coding system of buffer 5wDxDXtyU is Mule/ISO7. I would think this
> doesn't matter since the internal encoding is a UCS, but.... Maybe
> you can update your test case to set an appropriate
> buffer-file-coding-system to force the problem?
To reproduce it here, XEmacs 21.5-b27 "fiddleheads" (+CVS-20060521)
configured for `i686-pc-linux'.,
1. Download the latest latin-euro-standards and latin-unity packages,
extract them to /tmp/aidan/
2. LANG=C xemacs -vanilla
3. Evaluate the following;
(push "/tmp/aidan/lisp/latin-euro-standards/" load-path)
(push "/tmp/aidan/lisp/latin-unity/" load-path)
4. Evaluate the test case;
(let* ((temp-buffer (generate-new-buffer "5wDxDXtyU"))
begin end csets psets)
(insert (decode-coding-string "
>> [...] m\xc3\xb6glich
\xc6\x92 \xe5\x8d\x97" 'utf-8))
(setq begin (point-min)
csets (latin-unity-representations-feasible-region begin end)
psets (latin-unity-representations-present-region begin end))
(latin-unity-maybe-remap begin end 'iso-8859-1 csets psets))
That gives me a long list of warnings on “Obsolete key binding technique”,
and a result of iso-8859-1. It shouldn’t give me that result, because U+0192
cannot be, and was not, remapped to ISO 8859/1, and ditto for U+5357. The
coding system of the buffer is binary, but that shouldn’t be relevant, as I
Santa Maradona, priez pour moi!