From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct? Date: Mon, 31 May 2010 19:44:49 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1275350272 15406 80.91.229.12 (31 May 2010 23:57:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 23:57:52 +0000 (UTC) To: 6283@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 01 01:57:51 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OJErc-0006JD-01 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Jun 2010 01:57:48 +0200 Original-Received: from localhost ([127.0.0.1]:55153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJEra-0002Tj-T2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 31 May 2010 19:57:46 -0400 Original-Received: from [140.186.70.92] (port=53855 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJErV-0002Rx-Ro for bug-gnu-emacs@gnu.org; Mon, 31 May 2010 19:57:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJErU-0007Vj-L6 for bug-gnu-emacs@gnu.org; Mon, 31 May 2010 19:57:41 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34555) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJErU-0007Vb-Jj for bug-gnu-emacs@gnu.org; Mon, 31 May 2010 19:57:40 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OJEfG-0000vk-Ef; Mon, 31 May 2010 19:45:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 May 2010 23:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6283 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6283-submit@debbugs.gnu.org id=B6283.12753494943556 (code B ref 6283); Mon, 31 May 2010 23:45:02 +0000 Original-Received: (at 6283) by debbugs.gnu.org; 31 May 2010 23:44:54 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJEf7-0000vJ-P0 for submit@debbugs.gnu.org; Mon, 31 May 2010 19:44:53 -0400 Original-Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJEf5-0000vE-I2 for 6283@debbugs.gnu.org; Mon, 31 May 2010 19:44:51 -0400 Original-Received: by gwj19 with SMTP id 19so2985687gwj.3 for <6283@debbugs.gnu.org>; Mon, 31 May 2010 16:44:50 -0700 (PDT) Original-Received: by 10.150.141.3 with SMTP id o3mr5612465ybd.357.1275349489809; Mon, 31 May 2010 16:44:49 -0700 (PDT) Original-Received: by 10.151.143.21 with HTTP; Mon, 31 May 2010 16:44:49 -0700 (PDT) X-Google-Sender-Auth: d2Nf3vAO0UlsvAoPFMC7kw5kVjI X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 31 May 2010 19:45:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37465 Archived-At: On Mon, May 31, 2010 at 2:51 PM, Eli Zaretskii 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 `#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\