From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oliver Scholz Newsgroups: gmane.emacs.devel Subject: Re: require-hard-newlines to use newline Date: Mon, 07 Mar 2005 11:45:42 +0100 Message-ID: <87sm373fah.fsf@ID-87814.user.uni-berlin.de> References: <1605.220.255.169.59.1110075529.squirrel@www.stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1110193753 10654 80.91.229.2 (7 Mar 2005 11:09:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2005 11:09:13 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 07 12:09:13 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D8G63-00051n-PL for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2005 12:08:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8GPn-00078i-3K for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2005 06:28:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D8GMm-0006fh-Ee for emacs-devel@gnu.org; Mon, 07 Mar 2005 06:25:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D8GMW-0006ck-9z for emacs-devel@gnu.org; Mon, 07 Mar 2005 06:25:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8GMH-000642-4Y for emacs-devel@gnu.org; Mon, 07 Mar 2005 06:25:09 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1D8FmO-0002L2-Ll for emacs-devel@gnu.org; Mon, 07 Mar 2005 05:48:04 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1D8Fgi-0000wi-VS for emacs-devel@gnu.org; Mon, 07 Mar 2005 11:42:13 +0100 Original-Received: from dsl-084-058-043-048.arcor-ip.net ([84.58.43.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Mar 2005 11:42:12 +0100 Original-Received: from alkibiades by dsl-084-058-043-048.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Mar 2005 11:42:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 37 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dsl-084-058-043-048.arcor-ip.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:wjfEaYOQGilJxkF6P9qViUdijko= 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: news.gmane.org gmane.emacs.devel:34270 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34270 Richard Stallman writes: > Because, everywhere else in the buffer, the newline at the end of a > paragraph is hard. > > That doesn't seem like a convincing reason. > > Now suppose the user goes to another buffer to do his editing, and comes > back to this buffer a long time later. He does not remember the exact > sequence of edits he performed on that buffer -- in particular, whether he > typed RET or not. From moving point around, he observes that the buffer > contains "some text" followed by a final newline. > > If he did not finish the paragraph, he will probably assume the > newline is soft. If he did finish the paragraph, he will probably > assume the newline is hard. Either way, he might be wrong. > > So I think that use-hard-newlines should inhibit the effect of > require-final-newline. It is the only way to get reliable results. Sorry if I missed something: as I understand it the problem arises from the fact that `require-final-newline' will not only make sure that the *file* ends with a newline, but will that newline add to the *buffer*. If I understand things correctly, the problem would go away, if require-f-n would just add the newline when writing the file but not to the buffer (a bit similar to a function in `write-region-annotate-functions') . Then the user would only come to see it, if she reverts the buffer; in this case it is longlines.el's job to use its heuristics to detect whether the final newline is hard or soft. Oliver -- 17 Ventôse an 213 de la Révolution Liberté, Egalité, Fraternité!