"Jan D." <[EMAIL PROTECTED]> writes:
>> At first, I think xassert in lisp_data_to_selection_data
>> (xselect.c) is wrong. Here, obj is generated by a Lisp code
>> that may generate a multibyte string by error (as in the
>> current case). But, in general, an error in Lisp code
>> should not lead to abort. So, I propose this change. I
>> choose string_make_unibyte instead of string_as_unibyte to
>> avoid exporting Emacs' internal leading bytes.
>>
>> *** xselect.c 12 Feb 2005 09:54:46 +0900 1.148
>> --- xselect.c 12 Feb 2005 10:39:47 +0900
>> ***************
>> *** 1908,1914 ****
>> }
>> else if (STRINGP (obj))
>> {
>> ! xassert (! STRING_MULTIBYTE (obj));
>> if (NILP (type))
>> type = QSTRING;
>> *format_ret = 8;
>> --- 1908,1915 ----
>> }
>> else if (STRINGP (obj))
>> {
>> ! if (STRING_MULTIBYTE (obj))
>> ! obj = string_make_unibyte (obj);
>> if (NILP (type))
>> type = QSTRING;
>> *format_ret = 8;
>
> If the multibyte string is generated by an error and this is one of
> the places where we can detect the error, should we not keep the
> xassert?
I agree, but since the source of the error is in Lisp code, it would
be more helpful to signal an error rather than abort.
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
