[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: suggestion for reference manual update/clarification
- From: KHMan <keinhong@...>
- Date: Sun, 23 Mar 2008 12:45:34 +0800
> On Sat, Mar 22, 2008 at 10:59:21PM +0800, KHMan wrote:
>> Looking back from the beginning of the thread, yes, the reference
>> manual is terse and fat-free. I think it's intentional; I guess to
>> some extent, the intended reader, i.e. a developer, is expected to
>> know C and stuff like that, and be able drop down to look at the
>> sources, especially for examples of API usage.
> I hope you are not right that reference manual authors
> has intentionally omitted description of API functions.
Oh no, of course people do make mistakes and miss out things. I
meant that some familiarity with C is implied and descriptions do
not explain stuff in terms of exact or detailed behaviour. Also,
there may be internals or mechanisms that are somewhat exposed but
completely unofficial because they are not expected to be stable
> On the other hand I can understand that there can be desire
> to keep reference concise. I just pointed out some findings of
> mine that I think should be in reference. But I may be wrong.
Yes, perhaps you can suggest rewritten portions and post it to
this list so that the Lua authors and community can look at them.
Only bear in mind that others might be happy to disagree. The last
word of course lies with the Lua authors.
>> In an earlier post, you mentioned setting utf-8 on your computer,
>> but then you say, and I quote: "I do not know how they work under
>> Windows Unicode charset." Windows use UTF-16LE; I don't believe
>> you can set UTF-8 except in specific applications. You also use
>> the word "strange". You're sure you intend to use UTF-8 and not
> My mistake! I failed to say that my computer is running Linux.
> The sentence you quoted is purely speculative and I would
> probably do better not use it at first place since I do not
> use Windows.
Lua just treats strings as a segment of bytes. Where C functions
are called, the NUL may be significant. A character in a Lua
string is more of a basic compiler char data type, not a textual
character data type. Full-featured Unicode functionality can
easily exceed the size of a Lua binary itself, and limited feature
functionality is just asking for trouble. So, the developer is
free to use or implement an appropriate library.
slnunicode should be able to cater for common needs. But an awful
lot depends on what your needs are... processing, searching,
pattern matching, etc., or just moving data around as constant
strings. If you have usage examples or intended application
examples, you might get better or more detailed suggestions.
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia