phlip wrote:Hmm, maybe vim is picking up something and triggering some broken syntax highlighting mode? Weird.
Yeah, I don't know what's triggering it...the temp file just has the standard alphanumerical soup for a name, so it's not an extension. update
: it's stopped happening. It works fine in all terminals now. The only changes I can think of is (a) I installed vim-scripts, which I think has some colour schemes (although I assume it doesn't automatically "install" one); (b) I closed a VM (but I reopened it and it didn't affect vidir).
As for $EDITOR... perhaps you can just alias "emdir" as "env EDITOR=emacs vidir"? Alternatively, it wouldn't be hard to edit the script to check another environment variable...
Yeah, I'll use an alias. I like aliases.
Although ironically I won't be able to use it from emacs itself since it doesn't load my aliases when I execute a shell command. (I should start loading a shell mode buffer on startup and rebinding C-! to a function that sends a line to the shell buffer and if there's output, switches to it until you press 'q')
PM 2Ring wrote:
Interesting, but slightly scary: I'd prefer something that clearly shows you both the old & new names. Dumb mistakes in batch renaming can be messy to repair.
One technique I used to use a lot was "two-stage scripting": the batch renaming script doesn't do the renaming directly, instead, it builds a script full of rename commands, which you can check & modify in your editor before you run it.
I decided the risk was minimal since you'd be editing them interactively (even using macros etc, you could still step through them and approve each one), could use undo/redo, compare them to a directory listing etc. Possibly I'm just being complacent, though. If it was a script specifically for emacs, maybe it could open the original names in another buffer to the right, but that wouldn't work for arbitrary editors. I did consider having the original names off to the side in the same temp file, but I figured it was too likely to interfere with editing operations (and you'd have to quote filenames or otherwise handle spaces (not to mention newlines)
A code generation strategy is a good idea; alternatively, you could keep a record of the changes to enable (possibly automatic) reversion. Or a combination, where the script renames the files itself but generates a .undo-rename script in the directory that you can use to revert the changes. (Anyway, I'll see how vidir works before I bother writing a script myself.)
I thought about writing one, but I don't think I ever did. But there are a couple you can find online (I'll do the googling for you
); see this
. I feel like I've used the latter, but a long time ago.
. I'll use one of those next time.
Unless vidir works off the bat on Cygwin, in which case I could use that. (It might even work with native Windows Perl, for that matter - I don't know how portable Perl's library functions are.)
muddled different problems ]