From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: require-hard-newlines to use newline Date: Thu, 3 Mar 2005 18:33:13 -0600 (CST) Message-ID: <200503040033.j240XD022473@raven.dms.auburn.edu> References: <1483.220.255.172.231.1109730379.squirrel@www.stupidchicken.com> <200503020302.j2232fR21722@raven.dms.auburn.edu> <2750.220.255.172.231.1109734015.squirrel@www.stupidchicken.com> <1415.220.255.169.59.1109818150.squirrel@www.stupidchicken.com> <1404.220.255.169.59.1109889146.squirrel@www.stupidchicken.com> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1109896740 8737 80.91.229.2 (4 Mar 2005 00:39:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Mar 2005 00:39:00 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 04 01:38:59 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D70qB-0006Nw-PT for ged-emacs-devel@m.gmane.org; Fri, 04 Mar 2005 01:38:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D713O-00083Q-TE for ged-emacs-devel@m.gmane.org; Thu, 03 Mar 2005 19:52:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D712T-0007u7-N9 for emacs-devel@gnu.org; Thu, 03 Mar 2005 19:51:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D712O-0007si-Qx for emacs-devel@gnu.org; Thu, 03 Mar 2005 19:51:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D712O-0007sK-OH for emacs-devel@gnu.org; Thu, 03 Mar 2005 19:51:28 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D70nA-0001a0-9K; Thu, 03 Mar 2005 19:35:44 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j240Zh9N024558; Thu, 3 Mar 2005 18:35:43 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j240XD022473; Thu, 3 Mar 2005 18:33:13 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: cyd@stupidchicken.com In-reply-to: <1404.220.255.169.59.1109889146.squirrel@www.stupidchicken.com> (cyd@stupidchicken.com) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:34158 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34158 Chong Yidong wrote: Both of the newline ends the last line in a paragraph, as well as the newline on the following blank line, are hard. I believe that you are right on that one. However, there is another way to view things. I believe that the newline inserted automatically at the end of the buffer if `require-final-newline' is enabled should be soft. Here is my reasoning: I believe that people often save in the middle of a paragraph, but very rarely in the middle of a word. C-x C-s inserts a newline at the end of the file, but in the buffer that newline is just a nuisance. If you call end-of-buffer you go past the newline and you have to be careful to do C-b, or you are editing at the wrong place. Normally, there is nothing you can do about that, you just have to live with this (granted small) misfeature of `require-final-newline'. Because the newline is soft, if you are careless and start typing at the wrong place, you can trivially correct the situation with M-q. However, Longlines tries to make it convenient on you by translating the newline back into a space. Now you can just do end-of-buffer and immediately continue typing, without having to worry about remembering to type C-b. Wonderful. Making the newline hard would mess this up. So what is the problem? From what you told us, apparently that Longlines marks the buffer modified. Apart from that the feature (with _soft_ newline) seems perfect. I believe to remember that you said that Longlines is not included with Emacs. But you could ask the Longlines maintainer to put a function in after-save-hook that transforms the soft newline into a space, without marking the buffer modified. There is no need to mark the buffer modified, there are no changes that are going to be saved. On saving, filling should remove the trailing whitespace at the end of the buffer and put the newline back in, yielding exactly the same content as the file currently has on disk. After this change, it would seem that the problem disappears and everything is perfect. Does the above make sense or are there other reasons to make the newline hard? Sincerely, Luc.