Re: BeOS port news and public patch

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.