emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: require-hard-newlines to use newline


From: Chong Yidong
Subject: Re: require-hard-newlines to use newline
Date: Sun, 13 Mar 2005 01:14:32 -0500 (EST)
User-agent: SquirrelMail/1.4.3a

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]