Re: Making re-search-forward search for \377

[Eli Zaretskii <eliz@gnu.org>]

> From: Tyler Spivey <tspivey@pcdesk.net>
> 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.