Re: gratuitous changes

[Martin Stjernholm]

Miles Bader <address@hidden> wrote:

> > It uses after-change-functions, post-command-hook, first-change-hook
> > and write-contents-hooks. What's the problem with that?
> 
> It slows down editing. /.../

I took care to ensure that they run very fast in the normal case. In
the most common case, i.e. when there has been no preceding
modification, the post-command-hook function only does a single test
of a variable. When there has been a change the overhead still is
negligible compared to on-the-fly font locking. I don't think it's an
issue even on low end systems.

> Suppose some hook wrapped all the text in a visited file with an appropriate
> `modification-hooks' property, which would simply remove itself from any
> lines that were modified.  Then the file-write-time hook could scan through
> and only remove line-ending whitespace from lines that aren't wrapped by that
> property.

That's an alternative. I can see one problem with it: It's not
possible to avoid trimming of multiline edits, e.g. when blocks are
yanked. In my ws-trim package that's configurable.

Besides, the trimming wouldn't take place interactively. Whether
that's a drawback or a feature is of course a matter of taste. I like
the interactive way since it minimizes the experience of the extra
whitespace, i.e. edit a line, leave it, go back again and it'll
already be nice and tidy.