[Top][All Lists]

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


From: Kenichi Handa
Date: Wed, 13 Feb 2008 12:48:07 +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:

> > Before the unicode merge, this worked:
> >   (let ((str "a")) (aset str 0 (decode-char 'ucs #x100)))

> > In emacs-unicode-2 branch, there was a discussion about the
> > rightness of aset changing the multibyteness of a string,
> > and I changed the code to signal an error in the above case.

> An error sounds right.

For this:
  (let ((str "\300")) (aset str 0 (decode-char 'ucs #x100)))
an error may be ok.  But for the first example, although "a"
is currently treated as a unibyte string, I think it's more
like multibyteness-not-yet-decided, i.e. it's neutral about
the multibyteness.

> > But, I got reports claiming that the change breaks some of
> > already existing Elisp packages.  Although changing the

> Details?

Something like this code:

         (setq result (cons 
                       (let ((str (make-string 1 0)))
                         (aset str 0 (make-char 'japanese-jisx0208 ku ten))

although it's easy to fix it...

> > What do you think is the right thing for this matter?

> aset on strings is fundamentally problematic, so anything that restricts
> it further is good in my book (my own local Emacs disallows them
> plainly, and I rarely bump into code that needs it).

What is the fundamental problem?

Kenichi Handa

reply via email to

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