unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Chong Yidong" <cyd@stupidchicken.com>
Cc: teirllm@dms.auburn.edu, emacs-devel@gnu.org
Subject: Re: require-hard-newlines to use newline
Date: Wed, 2 Mar 2005 21:49:10 -0500 (EST)	[thread overview]
Message-ID: <1415.220.255.169.59.1109818150.squirrel@www.stupidchicken.com> (raw)
In-Reply-To: <E1D6g5c-0001RT-U5@fencepost.gnu.org>

>     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.

  reply	other threads:[~2005-03-03  2:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-02  2:26 (no subject) Chong Yidong
2005-03-02  3:02 ` Luc Teirlinck
2005-03-02  3:26   ` require-hard-newlines to use newline Chong Yidong
2005-03-02  3:55     ` Luc Teirlinck
2005-03-03  2:29     ` Richard Stallman
2005-03-03  2:49       ` Chong Yidong [this message]
2005-03-03 20:57         ` Richard Stallman
2005-03-03 22:32           ` Chong Yidong
2005-03-04  0:33             ` Luc Teirlinck
2005-03-04  0:56               ` Chong Yidong
2005-03-04  1:40                 ` Miles Bader
2005-03-04  6:02                   ` Chong Yidong
2005-03-04  9:55                     ` David Kastrup
2005-03-04 23:46                   ` Richard Stallman
2005-03-08  0:05                     ` Luc Teirlinck
2005-03-08  2:10                       ` Chong Yidong
2005-03-08  3:09                         ` Luc Teirlinck
2005-03-08  4:28                         ` Luc Teirlinck
2005-03-08 15:45                           ` Luc Teirlinck
2005-03-08 16:42                             ` Chong Yidong
2005-03-08 18:04                               ` Stefan Monnier
2005-03-08 18:12                                 ` Luc Teirlinck
2005-03-08 19:02                                   ` Stefan Monnier
2005-03-08 18:26                                 ` Luc Teirlinck
2005-03-08 16:03                       ` Richard Stallman
2005-03-08 16:39                         ` Chong Yidong
2005-03-09  9:45                           ` Chong Yidong
2005-03-11  1:46                           ` Richard Stallman
2005-03-11  9:10                             ` Chong Yidong
2005-03-11 10:25                               ` Kim F. Storm
2005-03-11 13:03                                 ` Chong Yidong
2005-03-11 14:32                                   ` Stefan Monnier
2005-03-11 14:57                                     ` Kim F. Storm
2005-03-11 15:08                                       ` Chong Yidong
2005-03-11 15:28                                         ` Stefan Monnier
2005-03-11 15:13                                       ` Chong Yidong
2005-03-11 15:30                                       ` Stefan Monnier
2005-03-11 16:11                                         ` Chong Yidong
2005-03-11 17:32                                           ` Stefan Monnier
2005-03-12  2:40                                             ` Chong Yidong
2005-03-11 22:29                                           ` Kim F. Storm
2005-03-12  2:23                                             ` Chong Yidong
2005-03-12 22:16                                   ` Richard Stallman
2005-03-12 23:53                                     ` Stefan Monnier
2005-03-14  3:00                                       ` Richard Stallman
2005-03-13  6:14                                     ` Chong Yidong
2005-03-14  3:00                                       ` Richard Stallman
2005-03-14  3:42                                         ` Chong Yidong
2005-03-15 18:39                                           ` Richard Stallman
2005-03-12 22:16                               ` Richard Stallman
2005-03-04 23:45             ` Richard Stallman
2005-03-05  2:03               ` Chong Yidong
2005-03-06  0:41                 ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2005-03-06  2:18 Chong Yidong
2005-03-07  5:02 ` Richard Stallman
2005-03-07 10:45   ` Oliver Scholz
2005-03-08  0:50     ` Luc Teirlinck
2005-03-08  1:43       ` Luc Teirlinck
2005-03-08  2:52     ` Richard Stallman
2005-03-08  1:31   ` Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1415.220.255.169.59.1109818150.squirrel@www.stupidchicken.com \
    --to=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=teirllm@dms.auburn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).