Re: require-hard-newlines to use newline

[Chong Yidong]

> It only does a part of the job.  It handles kill, but not registers,
> etc.  I think it is implemented at the wrong level.
>
>>     (defvar kill-filters nil
>>       "List of functions for converting a string before it is killed.
>>     Each function should accept a single argument, a string, and
>>     return a string.
>
> That is more the right idea, for the part that reads from
> the buffer.  But it is not correct to associate this with
> killing.  Think of it as a variant of buffer-substring.

By this, I'm guessing you mean going to a lower level, e.g. calling the
filter functions from inside buffer-substring.  I'll look into this, but I
doubt it's worth it.

The current behavior of longlines.el, which is to filter at the level of
kill-region and copy-region-as-kill, addresses the main requirement of
users -- removing the soft newlines when copying into another program or
yanking into a non-longlines buffer.  All the bugs here have been pretty
much ironed out.  It doesn't deal with *all* the situations where
filtering might be good, like copy-to-register, but we could simply make
those commands use the filter too.

buffer-substring is called in many, many places, and I'm not confident
that filtering is appropriate everywhere.  For example, fill.el calls
buffer-substring all over the place, and one feature of longlines is that
M-q still works as usual; changing buffer-substring may screw it up.

I suggest implementing the `kill-filter' variable I proposed; then I will
change longlines.el to use it, and we can put longlines.el into Emacs. 
This version of longlines.el will be the same as the existing
"third-party" longlines.el, except it won't use advice.  A future version
can implement something more elegant. (I have other plans for longlines.el
too, including providing word wrap for files which are already full of
hard newlines.)