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: search-forward in emacs23 lisp Date: Sat, 27 Mar 2010 15:31:48 -0500 (CDT) Message-ID: <20100327.153148.886429907165788179.rasmith@aristotle.tamu.edu> Reply-To: rasmith@tamu.edu NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1269781311 17795 80.91.229.12 (28 Mar 2010 13:01:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 28 Mar 2010 13:01:51 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Mar 28 15:01:46 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 1Nvs7V-0003Le-N1 for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Mar 2010 15:01:38 +0200 Original-Received: from localhost ([127.0.0.1]:33237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvru4-0004k9-3O for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Mar 2010 08:47:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nvcfg-0007LW-80 for help-gnu-emacs@gnu.org; Sat, 27 Mar 2010 16:31:52 -0400 Original-Received: from [140.186.70.92] (port=56852 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvcfe-0007KO-QZ for help-gnu-emacs@gnu.org; Sat, 27 Mar 2010 16:31:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nvcfd-0000lI-AP for help-gnu-emacs@gnu.org; Sat, 27 Mar 2010 16:31:50 -0400 Original-Received: from aristotle.tamu.edu ([128.194.75.5]:31030) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvcfd-0000l9-5V for help-gnu-emacs@gnu.org; Sat, 27 Mar 2010 16:31:49 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by aristotle.tamu.edu (Postfix) with ESMTP id 23D49E041C for ; Sat, 27 Mar 2010 15:31:48 -0500 (CDT) 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-Mailman-Approved-At: Sun, 28 Mar 2010 08:44:26 -0400 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:72507 Archived-At: The behavior of the search-forward function in emacs-lisp has changed in emacs23 in a way that breaks some scripts I use, in particular cgreek-tlg.el from Naoto Takahashi's cgreek package. This package includes facilities for reading files in the Thesaurus Linguae Graecae (TLG) containing both Greek texts and data about those texts, each in a format unique to the TLG. Parsing those files requires reading them into a buffer literally and searching for strings terminated by \xff (byte 255). Under emacs22, this only required (search-forward (char-to-string ?\xff)) However, under emacs23, char-to-string with an 8-bit argument (128 through 255) now returns a two-byte string (\x00\xff). So, these searches fail. I tried changing to unibyte-string. In fact, (unibyte-string ?\377) does return a string containing just one byte (255), as I've verified with what-cursor-position. However, (search-forward (unibyte-string ?\377)) doesn't match an occurrence of 255. Instead, it matches on the two-byte string \231\277 (\x99bf). That two-byte sequence doesn't appear to me to be a possible Unicode character (I thought the utf-8 representation of 255 would be \0xc1\0x3f). Perhaps this is something peculiar to utf-8-emacs? If I move to the buffer that contains the data to be parsed (which has its multibyte flag set to nil), then (search-forward (unibyte-string ?\377)) behaves as above. However, in that same buffer, a keyboard isearch-forward for \377 finds a \377 with no problem. So, what I need to know is: is there a way to make search-forward find a single 8-bit byte between 128 and 255? Robin Smith Department of Philosophy rasmith@tamu.edu Texas A&M University http://aristotle.tamu.edu/~rasmith/ 4237 TAMU Voice +1 979 845 5679 College Station, TX 77843-4237 FAX +1 979 845 0458