Re: Clear trailing whitespace on save, but not at the cursor

[Le Wang <l26wang@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3225 bytes --]

On Sat, Mar 24, 2012 at 3:57 AM, Aaron Meurer <asmeurer@gmail.com> wrote:

> I guess they're not the same in the sense that they're officially
> supported.  This was kind of the whole point of my question, which is,
> to what point are these things supposed to be the way you do things?
>
> Like I said, they can be problematic.  For example, take the seemingly
> innocent (add-hook 'before-save-hook 'delete-trailing-whitespace),
> which is the universally recommended way make emacs to clear
> whitespace on save.  As far as I can tell, with this active, it is
> impossible to save without clearing whitespace, unless you clear the
> hook.  With the global-set-key solution, I can easily save without
> clearing by doing M-x save-buffer.
>

I don't know about "universally recommended"; as you point out, this really
isn't a nice solution, at a minimum you should wrap
`delete-trailing-white-space' in a function you can configure to be on/off
on a per-file basis through a variable.

It's the easy solution.  And people like easy.

It's necessary for you to differenciate between recommended practices and
"practices I saw from a snippet posted to emacswiki".  `add-hook' solutions
are hacks.  The end-user should not have to call add-hook.  Package
maintainers should define minor-modes that manage hooks for the end-user,
or use the customize facilities to do something even smarter.  I'm sure
there is a "delete trailing white space" minor-mode out there somewhere.


> Hooks are fine if all they do is enable some mode, because I can
> easily turn that off if I don't want it. But other than that, you run
> into the above issue. Or maybe there's an easy way to bypass hooks
> that I just don't know about.
>
> There's other potential problems that are shared by hooks and monkey
> patching, like expected invariants that are no longer met.  I suppose
> the very existence of hooks means that there really can be no expected
> invariants about anything. But to me, this is impossible (you have to
> expect that what you use will work, or else you can't really say
> anything about your program).
>

Defadvice are hacks.  You (as the end-user) should not have to use it.

However, where would we be without it?

How would you change a certain aspect of a package you use daily?  You'd
redefine the relevant function.  Now, clearly defadvice provides a
structure that is superior to plain function redefinition.

The manual is clear on this.  Defadvice is a last resort solution, not a
line of first defense.

And by the way, I wasn't just referring to defadvice for monkey
> patching.  That actually seems like a better way to do it, because at
> least it warns you.  I was also talking about how in emacs lisp,
> pretty much everything is a global variable,



> so you can often "fix" something by just changing some internal variable
> to do what you want
> (usually with knowledge of how it is used internally).
>

You (as the end-user) should not have to do this. If you had to set a
"magic" internal variable to get what you want, then that's a bug in the
package.  The variables meant to be customized by the end-user are clearly
marked and documented through the customize facility.



> Aaron Meurer
>

-- 
Le

[-- Attachment #2: Type: text/html, Size: 4425 bytes --]