[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: search-forward in emacs23 lisp
From: |
rasmith |
Subject: |
Re: search-forward in emacs23 lisp |
Date: |
Sun, 28 Mar 2010 12:56:41 -0500 (CDT) |
From: Lennart Borgman <lennart.borgman@gmail.com>
Subject: Re: search-forward in emacs23 lisp
Date: Sun, 28 Mar 2010 19:10:59 +0200
>> Nope. That's exactly what caused the original problem (that is, the
>> code that broke was exactly what you suggest). Using either one of
>> these, what search-forward will look for is a two-byte string (in
>> other words, it undertakes to convert the high 8-bit character into
>> something like a utf-8 representation of it (\377 can't occur as the
>> first byte of a utf-8 character, which is probably what triggers
>> this).
>
>
> Oh, sorry. I read your first message now. It looks like you have found
> a problem with search-forward in this case and a bug in isearch. I
> suggest that you file a bug report.
I'll do that. To say a little more about the problem:
(char-to-string ?\xff)
produces a *two-byte* string, \0x00\0xff, while
(unibyte-string ?\377)
produces a *one-byte* string, as it should. However, when *either*
of these is given as an argument to search-forward, what it actually
searches for is the *two-byte* string \231\277. I don't really see
where that's coming from, since I thought the utf-8 representation of
\377 was \303\077 (\xc33f). I know that emacs23 uses a default
internal format with the name utf-8-emacs for buffers, but I don't
know its details.
Robin Smith
Re: search-forward in emacs23 lisp, Peter Dyballa, 2010/03/28
Re: search-forward in emacs23 lisp, Johan Bockgård, 2010/03/28