Re: search-forward in emacs23 lisp

[rasmith@tamu.edu]

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