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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
