help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: search-forward in emacs23 lisp


From: Lennart Borgman
Subject: Re: search-forward in emacs23 lisp
Date: Sun, 28 Mar 2010 19:10:59 +0200

On Sun, Mar 28, 2010 at 7:04 PM,  <rasmith@tamu.edu> wrote:
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Subject: Re: search-forward in emacs23 lisp
> Date: Sun, 28 Mar 2010 18:50:46 +0200
>
>> On Sun, Mar 28, 2010 at 6:39 PM,  <rasmith@tamu.edu> wrote:> Sorry to
>> reply to my own post, but the following rather ugly solution
>>> solves the problem of finding a single FF byte:
>>>      (while (/= (char-after) ?\377)
>>>        (forward-char 1)
>>>        )
>>>      (forward-char 1)
>>> This replaces
>>>      (search-forward (unibyte-string ?\377))
>>> which, in emacs23, no matter what I do, insists on turning the byte
>>> into the two-byte string \231\277 before searching.
>>>
>>> But surely there's a better way?
>>
>> Hi Robin,
>>
>> Someone else knows this much better than me and can explain the
>> details, but I believe that unibyte-string is a low level function
>> that you do not need here.
>>
>> How about just
>>
>>    (search-forward (char-to-string ?\377))
>>    or (search-forward (char-to-string 255))
>>
>> Does that work for you?
>
> 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.




reply via email to

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