> 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. > > That is true. But those kinds of files are in special formats, not > human-language text. What is the motive for setting use-hard-newlines > in one of those buffers?
Require-final-newline is a user option, and if a user customizes it to t then it is turned on for every buffer, even for human-language text. A user might do this if he want every file he edits to end in a newline. > 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. > > "Automatic line wrapping" is not a normal Emacs term, and I am not > sure what you mean by it. Do you mean Auto Fill mode? If so, > longlines can distinguish the two cases because the newline inserted > by Auto Fill mode is not at the end of the line. > > If it means something else, could you please say what? Like Emacs' built-in Refill mode, Longlines does filling after every user command, except that it uses its own filling functions (for various reasons that have to do with simulating the behavior of "word-wrapped" text editors.) In any case, it makes use of use-hard-newlines to keep track of hard and soft newlines. It is impossible to distinguish between a soft newline left at the end of a line by require-final-newline, and a soft newline produced by, e.g., a call to kill-line, simply by looking at the context. Both are soft, and both occur at the end of a line. Both newlines might even occur at the end of a buffer, if that was the final line. But the first is conceptually a hard newline, and should not be converted into a space by filling; whereas the second is a "real" soft newline. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
