🚀 go-pugleaf

In article <24551@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:

>~ Then, why you use ISO 10646? Can't we use ISO 2022?

>to actually know
>what characters are meant, you have to know what the special escape
>sequences are AND know how that particular small character set works.
>furthermore, this is now a stateful encoding, so you can't seek or anything.
>just horrible. at least with 10646, i know all teh characters NOW, and there
>is no state switching.

Very good.

>~ Then, how can I create a text file which contains both Chinese
>~ and Japanese?
>
>	i said i didn't know; presumably, there are magic commands (a la RTF)
>that change fonts.

Very good.

Then, isn't the magic commands a special escape sequence or something
like that?

Mustn't we know how that particular font specification works?

Doesn't the font specification make everuthing stateful, so we can't
seek or anything?

According to your criteria, 10646 is just horrible and utterly hopeless
to us Japanes.

Thus, 10646 can't be a internationally usable standard.

>~ Making everything English text is another fatal misdesign of Plan 9
>~ as an internationalized OS.
>
>	damned if i know where i said the text was english.

How damned Plan9 is. It is much better to be said "Not a tty" than
"iwmczal aslkdjf lskjancm aslkio" on inappropriate ioctl.

>~ If you are connecting to some server, you know the protocol you use
>~ in which meanings on error numbers are contained.
>
>	just wrong. i attempt to open a file. an error is returned.
>the protocol doesn't define nor restrict how that may have failed.
>sure we can guess common ones ('file does not exist'); but what about rare
>ones ("its bob's file and he's gone home")?

How can damned you think the state 'file does not exist' is represented
in English?

>~ >the problem is that a file server, say, may have an arbitrary
>~ >number of error conditions, many of which may not be known locally.

>~ Or, how can the client program know the severity of the error? Should
>~ client program retry on error? How many times? Or should the client
>~ abort the current transaction and retry? Or should the client
>~ abort the entire job?

>	good idea (not that it has anything to do with error numbers)!
>by default, we assume that file servers are working or not. but in general,
>it would be plausible for the file server to prefix its error message
>with a convential token indicating whether or not to retry.

The problem is that a file server, say, may have an arbitrary number
of its own convential error conditions, many of which may not be
represented by a convential token known locally.

>again, this
>should be a file server depependent thing and therefore cannot be tied
>to any particular set of error numbers.

Of course, this
should be a file server depependent thing and therefore cannot be tied
to any particular set of convential tokens.

>	and just in case you were wondering why this is being pursued,
>it shows why having international character sets isn't the same as i18n.
>you have to deal with things like errno and so on.

Internationalization of "errno" interpretation is a simple and
already-solved problem.

						Masataka Ohta