bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct?

[Eli Zaretskii]

> Date: Thu, 27 May 2010 18:56:51 -0400
> From: MON KEY <monkey@sandpframing.com>
> 
> On Thu, May 27, 2010 at 2:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> | characters have codes above octal 0377.  {....}
> >> `---- :FILE doc/lispref/searching.texi  (info "(elisp)Regexp Special")
> >>
> >> Shouldn't that be:
> >>
> >> "characters have codes above octal #o377"
> >
> > What's the difference between what's written and what you suggest?
> >
> 
> (string-equal "0377"  "#o377")  => nil
> (string-equal "0377"  "0377")   => t
> (string-equal "#o377" "#o377")  => t

Sorry, I don't see the relevance.  The manual talks about the
_numeric_ code of characters, not about their read syntax.  It uses
"octal 0377" to present values because octal notation of single-byte
characters is something many people are familiar with, regardless of
them being Lisp programmers or not.  After all, that is the codepoint
of the character.

> What isn't at all clear in the infos in general is that the octal (or
> FTM decimal, hex, etc. representations) for the literal raw-byte \255
> is arrived at with something more like:
> 
> (insert (char-to-string #o17777655))

This is explained in "Non-ASCII Characters".  But we generally try not
to advertise this issue too much, because there should be no good
reason for a Lisp program to create raw bytes.  Emacs is a text
editor, while raw bytes are not text

> FWIW It took me a coupla years to figure out what how to frob those
> values into a raw-byte and I still require to relearn it from the docs
> whenever I need to manually revert some raw-bytes or improperly
> encoded bit-rotted text using regexps.

It's hard to believe Emacs couldn't handle any such text in some other
way.  What "improper encoding" was that which Emacs couldn't handle?
Could it be that you simply gave up too early and tried to solve the
problem by treating text as bytes, while it really wasn't?