Re: BeOS port news and public patch

Hmm, forgot to CC myself again.
Please reply to this post instead, as the archives both on 
xemacs.org and gmane.org seems definitely unreliable, and I'm 
still spammed enough :-(

It seems after 30 minutes cvs is finally updating my tree...
The joy of using dialup :^)

François.

Selon François Revol <[email protected]>:

> 
> So, after digging a bit it seems to not be that hard.
> the windows redisplay code just implements textual_runs with WCHARs,
> so separate_textual_runs actually does the convertion while separating 
> the string.
> I suppose I should do the same in redisplay-beos, with chars, and my 
> own Qbeos_unicode coding. intl-win32.c declares Qmswindows_unicode in 
> complex_vars_of_intl_win32:
>   Fmake_coding_system
>     (Qmswindows_unicode, Qunicode,
>      build_msg_string ("MS Windows Unicode"),
>      nconc2 (list4 (Qdocumentation,
>                build_msg_string (
> "Converts to the Unicode encoding for Windows API calls.\n"
> "This encoding is equivalent to standard UTF16, little-endian."
> ),
>                Qmnemonic, build_string ("MSW-U")),
>         list4 (Qtype, Qutf_16,
>                Qlittle_endian, Qt)));
> 
> I suppose something like:
>   Fmake_coding_system
>     (Qbeos_unicode, Qunicode,
>      build_msg_string ("BeOS Unicode"),
>      nconc2 (list4 (Qdocumentation,
>                build_msg_string (
> "Converts to the Unicode encoding for BeOS API calls.\n"
> "This encoding is equivalent to standard UTF8, little-endian."
> ),
>                Qmnemonic, build_string ("BEOS-U")),
>         list4 (Qtype, Qutf_8,
>                Qlittle_endian, Qt))); /* there isn't really any endiannessin utf8...
> is there ? */
> 
> in an intl-beos.c might work. I didn't read the full doc for 
> Fmake_coding_system yet.
> Now I'm not so sure about the other stuff win32 declares, like 
> Qmswindows_multibyte_system_default and what they do...
> 
> While on intl-win32, does XEmacs need the complete locale or are 
> the locale related functions in this file only here to find about the
> system charset ?
> BeOS R5 doesn't have any localization system on its own, and use the
> i18n stuff for Unix apps (though it doesn't export any LC_* var).
> Zeta (BeOS R6) does have a locale kit, but it's not yet bound to the
> i18n stuff (so changing the language would export the correct LC_ vars). 
> 
> Also, the BeOS Terminal has a setting to use either of the 
> BFont available encodings ("latin-*", utf-8, mac roman), but of course 
> it's not reflected to the shell... So I suppose exporting 
> LC_ALL=something.UTF-8 will be needed to get the tty code use utf-8 
> (is it able to do so yet ?) one more reason to bind the Zeta locale kit 
> to i18n. (actually I wanted it to be closer to i18n, but I didn't design
> it :^)
> 
> I'll also have to add input-method support. BeOS has an API for that and
> already several methods for japanese and other languages, (there are quite 
> a lot of japanese users) but I don't know how to use that, since I don't 
> have much use for it (yet :).
> Basically it's about using the B_INPUT_METHOD_AWARE flag for BView, and 
> probably adding some support code, since I don't use BTextView.
> 
> Still, the question about filepath coding holds.
> In BeOS the convention is to use UTF-8, and the desktop shows 
> filenames as such. However sometimes filesystems (like the FAT) 
> don't translate paths properly from the original codepage. In 
> Tracker it just shows up as squares in the names, but I noticed 
> XEmacs tends to crash when it finds something it's not supposed 
> to in encoded strings (like a byte that would be part of a multi-byte 
> char but isn't).
> 
> François.
> 


--