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

[MON KEY]

On Mon, May 31, 2010 at 2:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Please be more specific, because I don't see any contradictions here.
> Overloaded terminology, maybe, but not contradictions.

The subject line of the original bugreport is:

"doc/lispref/searching.texi reference to octal code `0377' correct?"

Your position (if I understand correctly) is that the manuals use of
`octal 0NNN' is in keeping with an accepted practice outside of Emacs,
the Emacs manual, and Emacs Lisp reader syntax. You've said:

  "It uses "octal 0377" to present values because octal notation of
  single-byte characters is something many people are familiar with,"

  "It's not an Emacs convention to represent characters by their
  codepoints expressed in octal.  It's a widely accepted practice."

My contention is that w/re the manual's reference to non-ASCII
characters/codes and their non-decimal numeric representations the
manual is internally inconsistent in its application of a `convention'.

That this is so (as the excerpts below clearly indicate), my
contention is that the manual should consistently apply the
`#<Radian>NNN' notation as it is what Emacs exposes to the user
whereas Emacs/Emacs-lisp is unaware of and certainly doesn't expose
`octal 0NNN' notation in any immediate or functionally equivalent
manner to the user.

 ,---- (info "(elisp)Coding Systems")
 |
1 | The result of encoding, and the input to decoding, are not ordinary
2 | text.  They logically consist of a series of byte values; that is, a
3 | series of ASCII and eight-bit characters.  In unibyte buffers and
4 | strings, these characters have codes in the range 0 through #xFF
5 | (255).  In a multibyte buffer or string, eight-bit characters have
6 | character codes higher than #xFF (*note Text Representations::), but
7 | Emacs transparently converts them to their single-byte values when you
8 | encode or decode such text.
 |
 `----

 ,---- (info "(elisp)Regexp Special")
 |
1 | You cannot always match all non-ASCII characters with the regular
2 | expression `"[\200-\377]"'.  This works when searching a unibyte
3 | buffer or string (*note Text Representations::), but not in a
4 | multibyte buffer or string, because many non-ASCII characters have
5 | codes above octal 0377.  However, the regular expression
6 | `"[^\000-\177]"' does match all non-ASCII characters (see below
7 | regarding `^'), in both multibyte and unibyte representations, because
8 | only the ASCII characters are excluded.
 |
 `----

In lines 4 an 8 of the first excerpt alternative non-decimal numeric
references are given in radian notation.

In line 5 of the second example alternative non-decimal numeric
references are given in `octal 0NNN' notation.

Do you not see a contradiction of convention here?

Do you agree there is an intersection of subject scope?

What is the overloaded terminology shared of this intersection?

--
/s_P\