> 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.) _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
