Re: unicode internal
Stephen J. Turnbull wrote:
Check me on this, but it seems to me efficiency of these methods
(mutators) doesn't much matter, compared to access, which is going to
have to be fast-fast-fast because it's called from redisplay all the time.
yup. and we still have the problem of what implementation to use. most
efficient in space and speed would be to use page tables that index to
bit fields for different properties, but this is ugly to generalize.
Ben> well, `regexp-compile' is already in mule-trex.
Well, I'll be damned. For Mule coder code, it's remarkably regular looking.
do we dump trex? what the hell does it do, anyway?
Ben> or have a global var. just for these commands?
i meant, a user-settable global variable that controls the operation
only of query-replace-regexp and other user-level commands.
Ben> but how do i ensure that "traditional arabic"
gets used for
Ben> arabic and "times new roman" for western?
Does Times New Roman really do Arabic? If so, is it really all that
ugly?
yes and no. but it doesn't look as nice as the arabic-specific fonts.
Japanese has the analogous case, of course. You simply set the
precedence to { nice font for English, nice font for Japanese }, and
since the repertoire for the English font doesn't cover Japanese, you
win. I think this will handle the majority of such issues.
but japanese and chinese fonts cover the same space.
Another possibility would be to filter the font's repertoire.
Ie,
something like
if we have a language tag:
set font-priority-list = filter font-priority-list for language
for font in font-priority-list:
if character in font->XEmacs-allowed-repertoire
and font has glyph for character:
return font
So even if Times Roman has Arabic, we won't permit it.
right.
Ben> [[...]] are you assuming we can reliably store the
language
Ben> with the string's text property, and key off of that first?
strange, i completely don't remember writing this sentence.
ben