emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Stallman
Subject: Re: wdired.el 1.7 --- Rename files editing their names in dired buffers
Date: Wed, 7 Nov 2001 22:00:39 -0700 (MST)

    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.

I think you are right (sad to say).

        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?

They could go wrong if called from another Lisp function.
Your check for the current major mode will make sure there is 
no problem in other modes.  There could still be problems
in Wdired mode.

Aside from that, having one Emacs package advise another is not good
for maintenance.  When people see a call to downcase-word, they expect
they can see what it will do by looking at the source for
downcase-word.  They don't expect advice to be changing things.

    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.

Thanks.  That will be a good general feature, I think.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]