[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: require-hard-newlines to use newline

From: Luc Teirlinck
Subject: Re: require-hard-newlines to use newline
Date: Thu, 3 Mar 2005 18:33:13 -0600 (CST)

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]