[Top][All Lists]

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

Re: Coding system conversion error

From: Kenichi Handa
Subject: Re: Coding system conversion error
Date: Mon, 14 Feb 2005 10:02:34 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3.50 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

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

>>  I agree that signaling an error is better than xassert.
>>  But, it seems that a function in selection-converter-alist
>>  can return a multibyte string as long as we have a fixed
>>  rule about how to handle it.  And "converting to a unibyte
>>  string by string-make-unibyte" seems to be a good rule.

> String-make-unibyte might not do the right thing.  It's just a guess when we
> don't have any alternative.  In this case we have an alternative which is to
> signal an error.
> After all, this did catch an error in the handling of encode-coding-string
> with compound-text, so I think it's better to signal the error than to
> silently try to correct it.

I reconsidered this problem, and now I agree with you.  I
was at first negative on signaling an error in
lisp_data_to_selection_data because I was not sure it is
safe to do that.  But, I found that Fsignal is already use
in this function.  So, I've just installed these changes.

2005-02-14  Kenichi Handa  <address@hidden>

        * coding.c (encode_coding_string): Always return a unibyte string.
        If NOCOPY is nonzero and there's no need of encoding, make STR
        unibyte directly.

        * xselect.c (lisp_data_to_selection_data): If OBJ is a non-ASCII
        multibyte string, signal an error instead of aborting.

Ken'ichi HANDA

reply via email to

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