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

[Eli Zaretskii]

> Date: Fri, 28 May 2010 19:20:18 -0400
> From: MON KEY <monkey@sandpframing.com>
> Cc: 6283@debbugs.gnu.org
> 
> On Fri, May 28, 2010 at 3:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Sorry, I don't see the relevance.  The manual talks about the
> > _numeric_ code of characters, not about their read syntax.
> 
> I must be misunderstanding something.
> What is the numeric code of \255 ?

\255 is not a character, it's the numeric code itself.

> > It uses "octal 0377" to present values because octal notation of
> > single-byte characters is something many people are familiar with,
> 
> Where is this convention detailed/discussed in the manual?

It's not an Emacs convention to represent characters by their
codepoints expressed in octal.  It's a widely accepted practice.  If
we were to describe every convention in the world in the manual, 99%
of the manual would be devoted to describing conventions.

> Should it be, esp. as 0377 is not a representation exposed by the
> Emacs user level interface (at least none that that I'm aware of).

Again, this part of the manual is not about how Emacs represents
characters or reads them.  It's about their codes.

> > After all, that is the codepoint of the character.
> 
> Of which character?
> 
> 0377 doesn't have a character that I'm aware of.

In Unicode, it's a codepoint of LATIN SMALL LETTER Y WITH DIAERESIS.

But the text says "...many non-ASCII characters have codes above octal
0377".  It doesn't talk about a specific character here, just about
which codepoints are below it and which are above it.

> > 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
> 
> Thats just silly. Emacs accomodates noodling w/ raw-bytes because it
> is neccesary to edit them on occasion. Heck, Emacs w32 distributes
> with a dedicated executable just to edit binary data in hexadecimal
> form.

I didn't say that we are going to remove these features any time soon.
Just that the manual doesn't talk too much about this, to avoid
confusing users with issues that are both very complicated and very
obscure, and are rarely if at all needed on the Lisp level.

> It generally can. However, sometimes file encodings get out of whack
> over time and once they are more than a generation away from
> rightedness Emacs isn't always able to revert them.
> 
> The good thing is Emacs can do this and I'm very glad it does :)
> 
> Besides, its my prerogative how I choose to abuse Emacs into abusing
> my data.

Of course.  But why do you expect to find the description of such
abuse in the manual?