From: "Richard M. Stallman" <rms@gnu.org>
Cc: ihs_4664@yahoo.com, pogonyshev@gmx.net, monnier@iro.umontreal.ca,
emacs-devel@gnu.org
Subject: Re: Longlines and insert
Date: Wed, 16 Nov 2005 17:01:31 -0500 [thread overview]
Message-ID: <E1EcVLP-0004Qv-Af@fencepost.gnu.org> (raw)
In-Reply-To: <8764qt9u85.fsf@stupidchicken.com> (message from Chong Yidong on Tue, 15 Nov 2005 21:55:54 -0500)
> Maybe longlines-mode could provide a variable
> "longlines-inserted-LF-are-hard" and then use it in an
> after-change-functions hook to mark all inserted LF as hard when that
> variable is non-nil.
>
> I'd guess that the variable should be non-nil by default and only bound to
> nil at a few specific spots, hopefully all of them in longlines.el.
The problem with using an after-change-function is that the function
is only told that the text was changed in a particular region, not
what the change was. There is no way to tell whether a soft newline
encountered in that region is a legit soft newline, or one produced by
an (insert "foo\n") call.
A before-change-function can record the old text, and the
after-change-function can compare the new text with it. That way it can
see whether newlines were inserted.
However, if we really want a feature that makes all inserted newlines hard,
it would be easier to implement that within `insert' itself.
Let me be a little more specific: this would be a variable
`insert-string-filters', normally bound to nil. insert_string (in
insdel.c) checks the value of insert-string-filters passed to it. If
non-nil, it makes use of it as follows:
I think the added generality of that feature would, in this case, be
a mistake. It would make things slower and harder to use.
If the hard-newline variable is enough to do the job,
I would rather stick to that idea. It is simpler and less risky.
next prev parent reply other threads:[~2005-11-16 22:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <874q6fa1t0.wl%david.wallin@ul.ie>
2005-11-15 2:12 ` Longlines and insert Chong Yidong
2005-11-15 19:00 ` Kevin Rodgers
2005-11-15 20:41 ` Paul Pogonyshev
2005-11-15 22:22 ` Kevin Rodgers
2005-11-15 22:24 ` Kim F. Storm
2005-11-16 3:05 ` Chong Yidong
2005-11-16 10:48 ` Richard M. Stallman
2005-11-15 23:09 ` Stefan Monnier
2005-11-16 2:55 ` Chong Yidong
2005-11-16 4:27 ` Stefan Monnier
2005-11-16 22:01 ` Richard M. Stallman [this message]
2005-11-16 22:11 ` Chong Yidong
2005-11-17 19:22 ` Kevin Rodgers
2005-11-17 22:01 ` Paul Pogonyshev
2005-11-17 22:52 ` Kevin Rodgers
2005-11-18 15:28 ` Paul Pogonyshev
2005-11-19 1:55 ` Richard M. Stallman
2005-11-15 23:33 ` Ryan Yeske
2005-11-16 2:49 ` Chong Yidong
2005-11-16 3:02 ` Chong Yidong
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=E1EcVLP-0004Qv-Af@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ihs_4664@yahoo.com \
--cc=monnier@iro.umontreal.ca \
--cc=pogonyshev@gmx.net \
/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).