Martin Eisengardt

> I'm rather confused about the whole font name implementation and the rationale behind it. It seems a little overkill Yes. But that assumes the client has a know fontset...

To sum up: 1) UTF8 escape strings would be possible if we customize lexer; see https://www.lua.org/manual/5.3/manual.html#3.1 1.1) Since LuaJ supports it out of the box any source file saved as...

7. Maybe we will need a "readUtf8" too. So that older scripts will continue get non utf strings.

Why? At least term/window/monitor are objects. Putting their utf methods to some other place would be confusing. "read" is a global function. Putting the "readUtf8" somewhere else would be confusing...

Ah ok :-) The string and the new utf8 API are defined by lua standard itself. So we should indeed follow it. It's easier to document and easier to adapt...

> This shouldn't be as much of a problem, as they'll should just be printed using CC's latin1 codepage instead of the full unicode one. Yes, but on Java side...

A last decision before I change the code. currently the following charset is used by computer craft:  As far as I can see this is a variant of iso-8859...

Yes, of course. But think of following simple script: local s = string.char(252) print(#s) print(s) What do you expect? In current ccraft version you will get a "1" and a...

ok, I will try to find a solution. But it may not be very nice.

And now the third try. Now we are fully backward compatible! That means: If you do nothing you will have the same behaviour than previous CCraft versions. To use utf8...