From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Making re-search-forward search for \377 Date: Mon, 03 Nov 2008 06:21:08 +0200 Message-ID: References: <87tzaqporw.fsf@pcdesk.net> <87prlepk45.fsf@pcdesk.net> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1225686093 13006 80.91.229.12 (3 Nov 2008 04:21:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2008 04:21:33 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Nov 03 05:22:36 2008 connect(): Connection refused 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.50) id 1KwqxX-0000yl-0R for geh-help-gnu-emacs@m.gmane.org; Mon, 03 Nov 2008 05:22:35 +0100 Original-Received: from localhost ([127.0.0.1]:33988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KwqwP-0002X2-Vt for geh-help-gnu-emacs@m.gmane.org; Sun, 02 Nov 2008 23:21:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kwqw6-0002Wu-9j for help-gnu-emacs@gnu.org; Sun, 02 Nov 2008 23:21:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kwqw5-0002WW-I0 for help-gnu-emacs@gnu.org; Sun, 02 Nov 2008 23:21:05 -0500 Original-Received: from [199.232.76.173] (port=38346 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kwqw5-0002WS-Cg for help-gnu-emacs@gnu.org; Sun, 02 Nov 2008 23:21:05 -0500 Original-Received: from mtaout5.012.net.il ([84.95.2.13]:38057) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kwqw5-0007lb-3A for help-gnu-emacs@gnu.org; Sun, 02 Nov 2008 23:21:05 -0500 Original-Received: from HOME-C4E4A596F7 ([77.127.192.143]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K9Q00FVGPHW8141@i_mtaout5.012.net.il> for help-gnu-emacs@gnu.org; Mon, 03 Nov 2008 06:22:45 +0200 (IST) In-reply-to: <87prlepk45.fsf@pcdesk.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.1 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:59366 Archived-At: > From: Tyler Spivey > Date: Sun, 02 Nov 2008 01:12:10 -0800 > > I'm probably going to end up working with binary data in a temp > buffer. Doing more research, I want enable-multibyte-characters to be > off. Given that, if we go to *scratch* > and run M-X toggle-enable-multibyte-characters until that variable > becomes nil, doing C-Q 377 RET gives 0xff, which is what I want > (according to C-x =, C-u C-x = and M-x describe-char). Now to > match it, I try: > > (re-search-forward "\xff") - no luck > > What did you use to figure out that the multibyte version of that > character was 0x00FF? I found it out accidentally as a lisp error, but > none of the previously described commands (C-X =, M-X describe-char or > C-u C-x =) will show that it is 0x00ff, they just show FF. Why are you trying to use re-search-forward with octal codes such as \377? What are you trying to do? does the buffer you are searching hold human-readable text or does it hold binary data, i.e. raw bytes? In the former case, you need to use characters in the search string, not literal codes like \377 or xff, and the buffer should be in the (default) multibyte mode. \377 is not a character code, as far as Emacs is concerned, it's an encoding of some character. Do _not_ make a mistake of turning enable-multibyte-characters off and using raw bytes such as \377 for searching normal text, that way lies madness.