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

[Juan Leon Lahoz Garcia]

>>>>> "rms" == Richard Stallman <address@hidden> writes:

    rms> wdired.el looks clean in general; here are my specific
    rms> comments. I've cc'd emacs-devel so that they can see the
    rms> general principles I'm following.

Thanks for your comments. In general, I agree with them.

    >> ;; Theoretically, you cannot edit anything outside of the names
    >> ;; of the files in the wdired buffer. The return key, as well
    >> ;; as C-j and C-o are "unbinded" (but you can still "paste"
    >> ;; newlines or use another tricks to shoot yourself). If,
    >> ;; despite these precautions, you change something out of the
    >> ;; names, or add or remove lines, unpredictable renames would
    >> ;; be done. You are warned ;-).

    rms> Shouldn't it do something more effective to prevent nonsense
    rms> editing? For instance, it could use post-command-hook to
    rms> notice that newlines have been inserted and remove them.

Yes, I can do that. I'll make variable `post-command-hook' buffer
local. Not sure yet how can I notice that newlines have been inserted
efficiently (i.e. quickly), but I'll think about it.

Maybe a option could be to add certain property to the beginning of
each file with a filename in it.

    rms> It could also assume that any writable newline has been
    rms> inserted as part of a file name, and really put the newline
    rms> in that file name. Maybe that is really "the right thing".

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.

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

    rms> The use of advising in wdired.el is not a good idea, both on
    rms> general principle, and because it could mess up user
    rms> functions that call these advised functions. I think it would
    rms> be better to rebind the keys using substitute-key-bindings.

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.

Using `substitute-key-definition' is a valid option with "case
commands", anyway. But it doesn't for replace commands, sadly.

    rms> But other more specific approaches may be better. For
    rms> downcase-word and such, repeating M-l may work fine even
    rms> though some of the calls get an error. So maybe nothing needs
    rms> to be done for the case commands. Have you tried it? What
    rms> happens?

Yes, I tried it: the command yields an error and the cursor stays in
the same place, so you can't hold the M-l key pressed to downcase all
filenames. Several users email me with "complaints" about it.

    rms> For query-replace and such, we could make perform-replace
    rms> understand read-only text regions and skip them. That may be
    rms> useful in general. Please try editing perform-replace in this
    rms> way.

Yes, this would be the better solution. I'm not sure about if it could
affect another emacs packages. I'll take a look to `perform-replace'
and if I manage to find a way to change it, I'll send it to this list.

    rms> There are two problems in that doc string:

    rms> 1. The first line should stand on its own.

And, in conformance to "Tips for Documentation Strings", it should not
be wider than 67 characters. Wow, what a challenge for my limited
English :-)!


BTW, the Monday I posted version 1.8 to gnu.emacs.sources, with
support to editing file permissions.

--
Leon