(Sorry for leaving out a subject field) > Could this patch be checked in? When require-final-newlines is t, the > newline is inserted by (insert "\n"), which does not take > use-hard-newlines into account, so the newline is not marked as 'hard. > > Are you really _sure_ that a newline inserted by saving a buffer > should be hard if use-hard-newlines is enabled? I would guess that > people might occasionally save their work to file while in the middle > of a long paragraph, in which case the inserted newline should be > soft. I guess that if people want to mark the end of a paragraph > before saving, they would explicitly type RET. > > What situation are you thinking of that would motivate making C-x C-s > insert a hard newline?
As I see it, the rationale for turning on require-final-newline is that a particular type of file should always end in a newline. The user should type RET himself, but in case he forgets to do so, Emacs does it for him. So (newline) should be used. Nothing will go wrong when you save in the middle of a paragraph, since the code inserts the newline inside a save-excursion. The hard newline always goes *after* point, at the end of the buffer, where it won't get in the way. The specific problem I am trying to solve is with Longlines mode (which is not part of Emacs.) It is, in principle, impossible for Longlines to distinguish between the soft newline inserted by require-final-newline and the soft newline inserted by filling when performing automatic line wrapping. It therefore turns that newline into a space, with the effect that buffer-modified-p is always t if you try to save a Longlines buffer with require-final-newline. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
