Ar an tríú lá is fiche de mí Iúil, scríobh Stephen J. Turnbull:
> (Moved from the XEmacs Patches thread with the same Subject.)
>
> Aidan Kehoe writes:
>
> > > Well, since this shouldn't actually be happening :-) (and in
> > > practice is fairly unusual even for most European users, I
> > > believe),
> >
> > No it’s not. http://mid.gmane.org/f2g834$sds$1@sea.gmane.org ,
> > http://mid.gmane.org/87ll1xcm3r.fsf@xemacs.org . I could trawl the
> > lists some more if you want.
>
> My point here is about *performance* of an exception-based mechanism,
> which (as with all issues about the performance of coding systems) is
> that coding of text is a one-pass operation, and in almost all cases
> the process of handling an exception is simply not going to cause
> delay perceptible to a user.
You’ve done work in this direction, right? And it’s been basically
impossible to do, right?
> If this stuff were happening thousands of times a second in loops, I'd
> worry about it.
>
> We need a more reliable and more maintainable coding system framework.
> You've taken a step in that direction for Cyrillic, assuming that CCL
> can be considered reliable and maintainable when there's only one
> XEmacs developer who understands it at all. But then you say similar
> coding systems would be inappropriate for Latin scripts and advocate
> that kludge latin-unity instead, except maybe for Greek. Huh?
I don’t consider latin-unity especially a kludge, no more so than these
coding systems.
> > It would be appropriate to move iso-8859-7 to being this kind of
> > coding system, I think, since the Greeks don’t want ISO-2022
> > encoding either,
>
> Nobody wants ISO 2022 extensions in any ISO 8859 coding systems AFAIK.
And they wouldn’t get them if latin-unity was turned on in the appropriate
language environments by default. And it works on 21.4 too.
> > Mule-UCS was faster than the 21.5 utf-8 implementation for me in
> > practice--I’ve just double-checked this impression.
>
> And would you like to explain your methodology so others can replicate
> the experiment, and try to figure out where the slowness occurs?
Something like:
(setq sexp (byte-compile-sexp
'(let ((string (make-string 256 ?\000)))
(loop for i from 0 to 255
do (aset string i (int-to-char i)))
(list
(current-time-string)
(loop for i from 0 to #x10000
do (encode-coding-string string 'utf-8))
(current-time-string)))))
(eval sexp)
And there’s no real mystery as to why it is; Mule-UCS calls fewer C
functions, does less error checking, and does its table lookups in simpler
(and bigger) tables.
--
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
The one concern that I have about enabling font lock by default is that
it can be slow, i.e., when editing large files on relatively slow
hardware.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
XEmacs 21.5.x cannot display U+FFFD correctly. In "normal"
text files, a wrong glyph is shown, in web-pages viewed
with w3m.el only garbage Chinese characters are shown after
the first occurence of U+FFFD.
The problem seems to be that XEmacs maps U+FFFD to Big5:
(split-char (string-to-char (decode-coding-string "\357\277\275" 'utf-8)))
=> (chinese-big5-1 35 110)
and the reason for this seems to be that BIG5.TXT in the XEmacs
sources (which comes originally from Unicode.org) maps several Big5
characters to U+FFFD.
# WARNING! It is currently impossible to provide round-trip
compatibility
# between BIG5 and Unicode.
#
# A number of characters are not currently mapped because
# of conflicts with other mappings. They are as follows:
#
# BIG5 Description Comments
#
# 0xA15A SPACING UNDERSCORE duplicates A1C4
# 0xA1C3 SPACING HEAVY OVERSCORE not in Unicode
# 0xA1C5 SPACING HEAVY UNDERSCORE not in Unicode
# 0xA1FE LT DIAG UP RIGHT TO LOW LEFT duplicates A2AC
# 0xA240 LT DIAG UP LEFT TO LOW RIGHT duplicates A2AD
# 0xA2CC HANGZHOU NUMERAL TEN conflicts with A451 mapping
# 0xA2CE HANGZHOU NUMERAL THIRTY conflicts with A4CA mapping
#
# We currently map all of these characters to U+FFFD REPLACEMENT
CHARACTER.
# It is also possible to map these characters to their
duplicates, or to
# the user zone.
To verify this, I made the attached patch which comments out
all lines which map Big5 characters to U+FFFD.
With this patch, U+FFFD is displayed correctly in plain text files
(tested with an Xft build of XEmacs and a suitable font which has
a glyph for U+FFFD).
With this patch, web-pages containing U+FFFD are "mostly" correctly
displayed with w3m.el. "mostly" because U+FFFD is displayed as '???'
(3 question marks) in that case which is still not correct. But the
rest of such web-pages displays correctly.
I'm not sure whether commenting out the lines in BIG5.TXT which
map characters to U+FFFD is the right solution.
Maybe these characters should be mapped to the user zone instead
as suggested in the comment at the top of BIG5.TXT?
But at least this patch should help to illustrate where the problem
comes from.
For more details, please have a look at
http://bugzilla.novell.com/show_bug.cgi?id=293109
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Greetings -
How do I search the online xemacs-beta archives? I was just looking
to see if a particular user had reported a problem and I couldn't find
a search option.
Regards,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
(x-make-font-italic-xft "DejaVu Sans:size=14")
"DejaVu Sans-14:slant=110"
OK.
(x-make-font-bold-xft "DejaVu Sans:size=14")
"DejaVu Sans-14:weight=200"
OK.
(x-make-font-bold-italic-xft "DejaVu Sans:size=14")
"DejaVu Sans-14:weight=200"
Wrong, this should be "DejaVu Sans-14:weight=200:slant=110".
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
It seems to me that write-contents-hooks, local-write-file-hooks
and write-file-hooks are not functionning properly when made local: the
function files-fetch-hook-value destructively removes the t from the
local value, so the next time they are used, they don't work in
conjunction with the global value anymore.
I know that these hooks are special cases, but still, I believe this
behavior is wrong. Can somebody confirm that I didn't just blow a fuse ?
I soooo can't believe my own eyes...
--
MySpace: http://www.myspace.com/didierverna
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Is it possible to compile XEmacs using
--with-xft=emacs
but don't enable Xft support by default?
It would be nice to be able to choose between using Xft and X11 core
fonts by some lisp code in .xemacs/init.el.
I read on this list that the Xft support is not yet ready for general
use therefore it might not be wise to make it the default yet.
But it would be nice if users who are willing to experiment
were able to switch it on easily without having to recompile XEmacs.
Is that possible?
--
Mike FABIAN <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
I � Unicode
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta