[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Kenichi Handa
Date: Mon, 18 Feb 2008 13:00:37 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Stefan Monnier <address@hidden> writes:

> > That inefficiency may or may not be important in any given context.
> > Fixing it in casefiddle is definitely desirable.
> > But is it worth breaking all such packages just so that they
> > will optimize an operation that might not use much of the time anyway?

> Why work around the problem in `aset' if it isn't worth fixing in the
> original code?

But you wrote:

> > Then, shouldn't we start the experiment of inhibitting aset
> > on strings just now?
> But I do not think we're ready for that.  Maybe 10 years from now...

I want to avoid treating non-ASCII chars different from
ASCII.  Then, the only solution is to make aset work well
for multibyte characters.

> Especially since implicit conversion of a unibyte-string
> to multibyte is generally a bug in itself (since there are as many ways
> to do that as there are coding systems).

It's not a bug but I agree it's a very bad feature.  But for
the case (aset (string ?a) 0 MULTIBYTE-CHAR), I think it's
better to treat "a" as neutral, or in your terminology

Kenichi Handa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]