diff options
author | Mike Buland <eichlan@xagasoft.com> | 2010-11-19 05:54:14 +0000 |
---|---|---|
committer | Mike Buland <eichlan@xagasoft.com> | 2010-11-19 05:54:14 +0000 |
commit | 7c335ede527eaf4a3053ef35b1299141d34aaf40 (patch) | |
tree | 5ececc9181090cce540a5e4fbe28eda97e4e5c2b /support/vim/syntax | |
parent | 2fe32ba19571ff775a55f61eca355a46f269393e (diff) | |
download | libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.tar.gz libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.tar.bz2 libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.tar.xz libbu++-7c335ede527eaf4a3053ef35b1299141d34aaf40.zip |
I now think that this may not work out at all. It looks like if we want proper
Unicode handling we'll need to implement a series of codecs and converters as
well as tables of codepages and lookups. It'll be interesting, I guess, but
it makes me care a lot less about proper encoding. Anyway, UtfString uses
shorts instead of chars, so it's a step in the right direction, but still not
enough to be able to handle proper UTF-16 encoding, maybe UCS-2 encoding, but...
...that's lame. Bu::FBasicString has been generalized a bit with optimizations
from libc for char based strings. It also, unfortunately, still uses char-only
functions in several places, those all rely on char casting strings at the
moment just to get the thing to compile. Basically, it's not a good UTF-16
solution yet, and it may never be and remain compatible with char based strings.
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions