From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: require-hard-newlines to use newline Date: Mon, 7 Mar 2005 18:50:35 -0600 (CST) Message-ID: <200503080050.j280oZF28714@raven.dms.auburn.edu> References: <1605.220.255.169.59.1110075529.squirrel@www.stupidchicken.com> <87sm373fah.fsf@ID-87814.user.uni-berlin.de> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1110243613 8901 80.91.229.2 (8 Mar 2005 01:00:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2005 01:00:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 02:05:54 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D8TAI-0003rx-HK for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2005 02:05:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8TOf-0002r7-Ia for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2005 20:20:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D8TN7-0002OS-Ia for emacs-devel@gnu.org; Mon, 07 Mar 2005 20:18:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D8TMs-0002HQ-Gs for emacs-devel@gnu.org; Mon, 07 Mar 2005 20:18:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8TMs-0002Dg-Cw for emacs-devel@gnu.org; Mon, 07 Mar 2005 20:18:38 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D8Svy-0001CJ-Aw for emacs-devel@gnu.org; Mon, 07 Mar 2005 19:50:50 -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 j280oc9N020655; Mon, 7 Mar 2005 18:50:38 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j280oZF28714; Mon, 7 Mar 2005 18:50:35 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: alkibiades@gmx.de In-reply-to: <87sm373fah.fsf@ID-87814.user.uni-berlin.de> (message from Oliver Scholz on Mon, 07 Mar 2005 11:45:42 +0100) 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:34297 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34297 Oliver Scholz wrote: 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') . That would be OK for longlines to do but not for Emacs in general. Some people are already (very) upset that certain modes add newlines behind their back. The added newline is not easy to spot in the buffer. Going trough the effort of actually _completely_ hiding it would make matters worse. But longlines _already_ puts newlines in the buffer that are not present in the file and will _not_ be saved into it, so for longlines to do it would make sense. I would suggest that we keep writing a _soft_ newline to the end of the file (unless a newline, soft or hard, is already present) if both require-final-newline and use-hard-newlines are enabled, but that _only_ longlines handle it differently. Longlines treats soft and hard newlines similarly to the way for instance the AbiWord word processor does, which is very different from the way Enriched mode treats them. Soft newlines do not exist in the actual file. Every newline occurring in the file is a hard newline. Using longlines-mode for a file apparently only makes sense if you always use it if you edit that file (for instance, if you set it through a file local variable). I suggest that longlines treats final newlines the same way AbiWord does. _Always_ add one internal final newline to the file (_maybe_ even regardless of require-final-newline), that _never_ shows up in the buffer. (But _tell_ the user in the docs that you are doing so.) Applications that insist on a final newline will not recognize the extra newline as internal and will be happy. Note that Enriched mode, in contrast with AbiWord and longlines stores soft newlines as a single newline and sequences of N hard newlines as sequences of N + 1 newlines, in line with RFC1896. Sincerely, Luc.