Re: BeOS port news and public patch

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

> 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 :-(

See
http://article.gmane.org/gmane.emacs.xemacs.beta/14982

What's unreliable about the gmane lists?

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

You are using the cvs -z switch, right?

pcl-cvs also reads your ~/.cvsrc, BTW.

Here is mine:

# Set the compression level.
cvs -z3
# Do not print the list of tags for this file.
# log -N
# Use the unified output format.
diff -u
rdiff -u
# Prune empty directories.
update -Pd
# Prune empty directories.
checkout -P

Sorry if I'm stating the obvious.

Adrian

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

-- 
Adrian Aichner
 mailto:[email protected]
 http://www.xemacs.org/