From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: mode line eol char indication Date: Wed, 31 Dec 2008 21:44:57 -0800 Message-ID: <006201c96bd4$152bf190$0200a8c0@us.oracle.com> References: <005701c96b9a$243839d0$c2b22382@us.oracle.com> <495C1A49.3040009@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1230788721 6081 80.91.229.12 (1 Jan 2009 05:45:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Jan 2009 05:45:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Jason Rumney'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 01 06:46:30 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LIGO6-0003zV-DZ for ged-emacs-devel@m.gmane.org; Thu, 01 Jan 2009 06:46:30 +0100 Original-Received: from localhost ([127.0.0.1]:39939 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LIGMr-0006SC-MK for ged-emacs-devel@m.gmane.org; Thu, 01 Jan 2009 00:45:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LIGMm-0006QR-Qh for emacs-devel@gnu.org; Thu, 01 Jan 2009 00:45:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LIGMk-0006Od-Ip for emacs-devel@gnu.org; Thu, 01 Jan 2009 00:45:07 -0500 Original-Received: from [199.232.76.173] (port=41430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LIGMk-0006Oa-EX for emacs-devel@gnu.org; Thu, 01 Jan 2009 00:45:06 -0500 Original-Received: from rcsinet13.oracle.com ([148.87.113.125]:42229 helo=rgminet13.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LIGMi-0001Zj-0U; Thu, 01 Jan 2009 00:45:04 -0500 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n015jdLW002785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jan 2009 05:45:40 GMT Original-Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n015jWGZ010898; Thu, 1 Jan 2009 05:45:33 GMT Original-Received: from dradamslap1 (/24.5.134.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Jan 2009 05:44:57 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <495C1A49.3040009@gnu.org> Thread-Index: Aclrr2jk2s7RTYfuRnu+C/kU97JOngAISRYQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt700.oracle.com [141.146.40.70] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.495C585B.0065:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:107497 Archived-At: > > * The non-"nontrivial" eol convention, represented by `:', is > > presumably what is meant by "usually", that is, a newline char. > > But a newline eol is also sometimes represented by `(Unix)'. > > Why? And why is this called "nontrivial" - why is it more > > nontrivial and more usual than the other possibilities? I meant "trivial", sorry. The doc claims that line endings other than newline are nontrivial. > In Emacs 20, only the single character indications were used, > but people found them confusing. But the full word indications > are too long for many people, so now we use the single > character when the newline format is native for the platform > Emacs is running on, and the full word when it is non-native - > this change occurred in 21.1 IIRC. Unix line ends are > non-trivial (I think you too meant "trivial" here, for UNIX.) > because they are what Emacs uses internally - no conversion > is required. What's trivial for the implementation shouldn't be behind characterizing this line ending to the user as more trivial. Why would a user care which is easier to implement? > They are more usual for users of GNU based platforms > because GNU is based on unix conventions. Yes, and less usual for users of other platforms. But who cares? My argument is not that one or the other is more trivial or more usual. It's that: * Neither is more trivial (for the user) or more usual (for the user). * It's unimportant whather one is in fact more trivial or more usual. Such a characterization is not explained in the doc anyway, and it just makes the doc less understandable. > > Why `:'? Why `\' (is there some relation to the DOS directory > > separator?)? Why `/'? > > Originally : was was based on the unix PATH separator, and \ > on the DOS directory separator. / was made the Mac indicator > because like the DOS separator, it is not straight up and down, > but it leans a different direction than DOS. I think at some > point during 20.1 pretest, we had / for Unix and : for Mac, > until someone pointed out that : was less noticeable, so that > should indicate the trivial Unix line-end. Well, all of that is a historical explanation, and it gives a bit of the rationale accepted at the time, but it's not very convincing as to why it's the best choice or why we should have two different representations for each line ending. Not to mention why the doc should be so convoluted trying to explain it. To me: 1. There is no logical connection with the path separator or the directory separator that is used for a given platform and the line ending used for that platform. That's an artificial connection that is too cute by half. We're asking users to guess the line ending based on the platform, and guess the platform based on either a path separator (for UNIX) or a directory separator (for Mac/DOS). (Guess what this means: `:'? It's the UNIX path separator, so this buffer has UNIX line endings.) If we're trying to indicate the _line ending characters_, then lets just say what they are: C-j, C-m, or C-j C-m. 2. Unix, DOS, an Mac are preferable to :, \, and /. Much clearer. 3. \n, \n\r, and \r would also be preferable to :, \, and /. 4. C-j, C-j C-m, and C-m would also be preferable to :, \, and /. 5. We should pick just one label for each line-ending, not have two alternatives for each. Either name the platform or name the line ending, consistently, always. 6. If the aim is to indicate the platform, then use Unix, DOS, and Mac. If the aim is to indicate the line ending, then use \n, \n\r, and \r.