From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct? Date: Sat, 29 May 2010 09:45:53 +0300 Message-ID: <83sk5btdcu.fsf@gnu.org> References: <83vda9md09.fsf@gnu.org> <83sk5cmr8k.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1275151611 26392 80.91.229.12 (29 May 2010 16:46:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 29 May 2010 16:46:51 +0000 (UTC) Cc: 6283@debbugs.gnu.org To: MON KEY Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 29 18:46:49 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 1OIPBK-00064c-2B for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 May 2010 18:46:45 +0200 Original-Received: from localhost ([127.0.0.1]:41884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIPBH-0005xq-08 for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 May 2010 12:46:39 -0400 Original-Received: from [140.186.70.92] (port=46219 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIOKH-0001yn-He for bug-gnu-emacs@gnu.org; Sat, 29 May 2010 11:51:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIFz9-0006TY-2E for bug-gnu-emacs@gnu.org; Sat, 29 May 2010 02:57:32 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60390) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIFz8-0006TU-Uu for bug-gnu-emacs@gnu.org; Sat, 29 May 2010 02:57:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OIFoz-0005QB-Kr; Sat, 29 May 2010 02:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 May 2010 06:47:01 +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.127511558120831 (code B ref 6283); Sat, 29 May 2010 06:47:01 +0000 Original-Received: (at 6283) by debbugs.gnu.org; 29 May 2010 06:46:21 +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 1OIFoL-0005Pw-6h for submit@debbugs.gnu.org; Sat, 29 May 2010 02:46:21 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIFoI-0005Pr-Nb for 6283@debbugs.gnu.org; Sat, 29 May 2010 02:46:19 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L36005005FYE600@a-mtaout20.012.net.il> for 6283@debbugs.gnu.org; Sat, 29 May 2010 09:45:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.111.84]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L360034O5GGJ160@a-mtaout20.012.net.il>; Sat, 29 May 2010 09:45:53 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 29 May 2010 02:47:01 -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:37385 Archived-At: > Date: Fri, 28 May 2010 19:20:18 -0400 > From: MON KEY > Cc: 6283@debbugs.gnu.org > > On Fri, May 28, 2010 at 3:15 AM, Eli Zaretskii 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?