Re: (insert 8000) crashes XEmacs 21.2.16
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Hrvoje> That would be a bad idea, I think. There could be
code
Hrvoje> that assumes that stuff in [0, 256) range is Latin 1, or
Hrvoje> that internal representation is independent of the
Hrvoje> selected environment.
Good. Let's smoke those bad assumptions out. Ebola Redux! :-)
Not now, John. :-)
Yes, we'll exorcise Ebola sooner or later. The bulk of the work has
been done, and we *think* we've faced the worst of the consequences.
Now we can afford time to think about the issues and we needn't rush
into anything.
Case in point: a lot of code tries to increment characters, and gets
integers in return. The code works because insert and friends work
reasonably well with integers. If/when we modify insert to barf on
integers, (1+ ?a) will need to signal an error instead of returning
98. (It could also return ?b, but that's too ugly to think about.)
Of course I'm only about 10% serious. But I think this is on
the
agenda anyway. I see no good reason why Latin-1 should be
privileged once we get the 1-byte buffer stuff working, and a very
good reason why it shouldn't be (subtle bugs). In fact, putting the
default interpretation of ?\xA1 under user control is _exactly_ the
point of the 1-byte buffers.
It's impossible to bring the interpretation of ?\xA1 under user
control because such things are evaluated at read-time, not at
run-time. (That's an important property of Lisp.) I suppose you
could make (insert #xA1) do the "right" thing at run-time, but I think
it would only create more confusion. As a certain lady would say, bad
gut feeling.
To my mind, the real question may very well be timing. Do we
implement the 1-byte buffers first, and then try to flush out the
Latin-1 assumptions hidden throughout (possibly, anyway) the code?
As I pointed out above, there is no need to hurry with the latter.
There are much more important things to worry about in Mule, both with
the internals and with the interface.