Re: wdired.el 1.7 --- Rename files editing their names in dired buffers

[Stefan Monnier]

> Yes, I can do that. I'll make variable `post-command-hook' buffer local.

Beware.  Hooks are not variables (even though they look very much alike).
They should only be manipulated with `add-hook', `remove-hook', `run-hooks'
and friends.
`add-hook' has a `local' argument if you want to add a hook only in the
current buffer.

> Maybe that is really "the right thing", as you say, but I just make a
> quick test, and I noticed that dired.el doesn't work well with
> filenames with newlines in it. At least `dired-get-filename' have
> problems (and wdired.el relies heavily in this function), and marking
> commands for the filename portion after the newline is allowed, but it
> does not have sense.

Indeed, dired doesn't work well with such filenames and it's
difficult to fix in general.  Basically, we need to change the
`insert-directory' command to mark the file names with a special text-property
so that dired doesn't need the regexp magic any more.

[ of course, if `insert-directory' uses plain `ls', it will need the regexp
  magic, but at least dired won't need it any more and in cases where
  we don't use plain `ls' but ls-lisp (for example), we can do better. ]

> IMHO, It would be better to fix dired.el before (if it can be done, I
> think that it is difficult).

If we "fix" it as outlined above it will fail if the \n comes
out of `ls', but not if it comes out of `wdired'.  I.e. the user
of wdired will be able to insert a \n fine and the current dired
session will handle properly.  Of course, next time dired is called
on this directory, it might choke, but wdired doesn't need to care
any more.

> I'm think that I don't understand what you are saying. All advises
> check that the current mode is `wdired-mode', to avoid mess up
> anything. Maybe am I missing some cases in which something can be
> wrong?
> 
> Also, I don't know why is not good by general principle to advice
> functions (there must be a good reason, because standard Emacs
> packages doesn't use advice.el). I would like to know it.

The problem is that it subtly changes the semantics of those commands,
and that this change is not visible in the code of those commands.
So it works, but it's better to fix those commands directly.
That doesn't mean `advice.el' is evil, but that it should only be
used when you cannot change the command (f.ex. if you want your package
to work with older releases).


        Stefan