From: MON KEY <monkey@sandpframing.com>
To: 6283@debbugs.gnu.org
Subject: bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct?
Date: Mon, 31 May 2010 19:44:49 -0400 [thread overview]
Message-ID: <AANLkTimtBB1wmPv6HxYsDcVbeFNp17Kcm_mmfQluTI7C@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimxocCwSwup6COdhYZy6E7minAtJc_ec1yNCxOG@mail.gmail.com>
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\
next prev parent reply other threads:[~2010-05-31 23:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 17:28 bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct? MON KEY
2010-05-27 18:10 ` Eli Zaretskii
2010-05-27 22:59 ` MON KEY
2010-05-29 14:28 ` Kevin Rodgers
[not found] ` <AANLkTikjCByug1U69tbhsnmS4c1VXSNzoqAOAxmbt3bI@mail.gmail.com>
2010-05-28 7:15 ` Eli Zaretskii
2010-05-28 23:20 ` MON KEY
2010-05-29 6:45 ` Eli Zaretskii
2010-05-31 5:35 ` MON KEY
2010-05-31 18:49 ` Eli Zaretskii
2010-06-01 0:24 ` MON KEY
2010-06-01 18:38 ` Eli Zaretskii
2010-06-02 19:41 ` MON KEY
2010-06-03 14:39 ` Kevin Rodgers
2010-05-31 14:45 ` MON KEY
2010-05-31 18:51 ` Eli Zaretskii
2010-05-31 23:44 ` MON KEY [this message]
2010-06-02 16:06 ` MON KEY
2010-06-02 17:30 ` Chong Yidong
2010-06-02 17:46 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimtBB1wmPv6HxYsDcVbeFNp17Kcm_mmfQluTI7C@mail.gmail.com \
--to=monkey@sandpframing.com \
--cc=6283@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).