From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: rasmith@tamu.edu Newsgroups: gmane.emacs.help Subject: Re: search-forward in emacs23 lisp Date: Sun, 28 Mar 2010 12:04:01 -0500 (CDT) Message-ID: <20100328.120401.200754749763864021.rasmith@aristotle.tamu.edu> References: <20100327.153148.886429907165788179.rasmith@aristotle.tamu.edu> <20100328.113915.866357745907943848.rasmith@aristotle.tamu.edu> Reply-To: rasmith@tamu.edu NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269795879 29409 80.91.229.12 (28 Mar 2010 17:04:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 28 Mar 2010 17:04:39 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: lennart.borgman@gmail.com Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Mar 28 19:04:35 2010 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvvuc-00058a-Rr for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Mar 2010 19:04:35 +0200 Original-Received: from localhost ([127.0.0.1]:53422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvvuc-0000OU-DE for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Mar 2010 13:04:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvvuD-0000OP-MB for help-gnu-emacs@gnu.org; Sun, 28 Mar 2010 13:04:09 -0400 Original-Received: from [140.186.70.92] (port=59987 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvvuC-0000OH-9c for help-gnu-emacs@gnu.org; Sun, 28 Mar 2010 13:04:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvvuA-0007AI-MG for help-gnu-emacs@gnu.org; Sun, 28 Mar 2010 13:04:08 -0400 Original-Received: from aristotle.tamu.edu ([128.194.75.5]:63552) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvvuA-00079z-IC for help-gnu-emacs@gnu.org; Sun, 28 Mar 2010 13:04:06 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by aristotle.tamu.edu (Postfix) with ESMTP id 9D03AE041C; Sun, 28 Mar 2010 12:04:01 -0500 (CDT) In-Reply-To: X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:72516 Archived-At: From: Lennart Borgman 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, wrote:> Sorry to= > reply to my own post, but the following rather ugly solution >> solves the problem of finding a single FF byte: >> =A0 =A0 =A0(while (/=3D (char-after) ?\377) >> =A0 =A0 =A0 =A0(forward-char 1) >> =A0 =A0 =A0 =A0) >> =A0 =A0 =A0(forward-char 1) >> This replaces >> =A0 =A0 =A0(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). Robin Smith