[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.
Re: search-forward in emacs23 lisp, Peter Dyballa, 2010/03/28
Re: search-forward in emacs23 lisp, Johan Bockgård, 2010/03/28