Re: require-hard-newlines to use newline

[Luc Teirlinck <teirllm@dms.auburn.edu>]

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.