Re: BeOS port news and public patch

>>>>> "François" == François Revol <[email protected]> writes:

    François> I used to not reply-to-all, but the current trend of
    François> mailing list to not set the reply-to to the list really
    François> bothers me.

Well, I refuse to cater to broken software.  The only thing that keeps
a reply-to-list-else-reply-to-reply-to-else-reply-to-author function
from being trivial to implement is the presence of lists that munge
reply-to; even then it's easy unless the munging makes it impossible.
Sadly, some popular MUAs took years to implement "Reply-To" correctly,
and now that most lists have a "List-Post" header, it's criminal that
they don't get reply-to-list right.

    François> Yes I know that, however in some places the distinction
    François> of charsets from encodings is a bit blured...

Not in Mule, I don't think, except for the occasional presence of
references to "MIME charsets" and some low-level facilities in
latin-unity.

    François> Argh, right, 2 bits are used by the list object to tell
    François> the type.

Actually, I submitted a patch to make characters 31 bits and integers
30 bits, but that was vetoed by people who claim to be editing files
with > 2^29 bytes in them, so they need 30 bits for positive buffer
sizes....  Even with that patch you still have to work around the code
points used by Mule, so it's not necessarily worth it.

    François> It just uses a predefined font (it's customizable) for
    François> unicode planes not supported by the selected font.  I
    François> believe FreeType supports that now too.

Maybe, but that's simply too inflexible to be acceptable.  Maybe Pango
does better, but I don't know if we could use Pango.

    François> My point was to try getting XEmacs to give my UTF-8
    François> directly, since it already uses multibyte internally,
    François> instead of getting all those charsets and having to
    François> convert all them back to utf-8 for display, taken that
    François> the redisplay code is already quite slow.

Well, take a look at the redisplay code.  At some point you have a
Dynarr full of characters (ie, long int widechars, not multibyte
strings) to represent a row of glyphs on the window.  Those characters
can be fed directly to ichar_to_unicode, which is a fast table lookup.
If you want to use UTF-8, you will then have to convert from poor
man's UTF-32 to UTF-8, but there is no way to avoid that until we are
using UTF-8 internally, which will take some time to implement.  Seems
like broken API design though---the font library is just going to
convert back to UTF-32 so it can index through a CMap to an array of
glyph descriptors....

    François> it's not done from the window thread

"Thread"?!?  Good luck....  Emacs was not written to be threaded.
This is going to be hard to do well.  You are going to have to do
substantial refactoring to get reasonable efficiency, I'm afraid.

    François> I think it's much faster to convert between Unicode
    François> encodings than it is to convert between all those
    François> charsets.  (or maybe not ?)

It's a close race.  Remember, the Mule character to Unicode
conversions have to be table lookups anyway for the majority of
characters.  We just have a separate table for each charset.  (The
implementation is actually more complex than that because it also
supports more general char-tables.)

    François> Yes, it's just that I hoped I could have not the need
    François> for that, but it seems unlikely.

No, currently all Emacsen require the conversion.  I'm working on
UTF-8-ization, but the first stage is going to simply use
UTF-8-encoded Mule characters in buffers and strings, instead of the
current "leading byte" representation.  Then I'll start working on
putting Unicode inside, which will require conversions in a lot of
places because there are many, many functions in XEmacs which want to
know which charsets are in use.  I'm not sure what strategy is being
used in GNU Emacs's "emacs-unicode" branch.

This requirement of the conversion function does not go away when we
go to true Unicode orientation.  We do get the ability to characterize
many charsets (eg, Cyrillic or Korean Hangul) by blocks of Unicodes,
but we will still need to be able to disentangle Latin-2 from Latin-3
for legacy environments, and the bigger issue of Unihan requires this
facility.

Also, currently Emacsen are quite stupid about identifying
_languages_, but it should be obvious that with an appropriate pair of
_subsets_ of ISO 8859-15 you could distinguish between German and
French with high accuracy.  Mozilla already does this.  So, OK, maybe
we really don't need to know the difference between Latin-2 and
Latin-3 in an Unicode environment, but with a more flexible definition
of "charset" (ie, Unicode subset) we can do a lot of interesting things.

So Emacs charsets really shouldn't go away IMHO; we can make good use
of similar facilities even if they're not needed to survive the Tower
of ISO 2022, oops, Babel.

-- 
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.