Re: [gcmd-dev] [NEW] Advrename on steroids

[Michael]

>     regex: '\b(\w)(\w*)\b'   replace: '\u\1\L\2\E'

Does this work for you ? For example with 'This is a Long Foo' -> 
'ThisIsALongFoo' ?

> CamelCase -> long file name
> 
>     regex: '\p{Lu}'   replace: ' \l\0

Gives here: ThisIsALongFoo -> thisisalongfoo which is basically ok but it does 
not insert spaces.

> > Would be nice to also have 'remove all blanks' as an option then.
> 
>     regex: '\s+'   replace: ''

Yes of course, i just think one would expect it in the drop down too (as 
convenience).

By the way, is it correct the regex list is worked top down ? But when comes 
the space remover into play ? (Like, when i want to remove spaces first and 
only afterwards apply another replacing) ?

> IMHO the best approach here is to implement support for storing/loading
> advrename settings - this way there'd be convenient way for defining
> by user its own rename schemas.

Yes, profiles, that would be great, since there always are some complex 
operations for different cases. In fact, i'm repeating typing them in over and 
over again.

> > Somehow i seem to see ctime instead, or at least it's not updated
> after
> > 'apply'.
> 
> You're right, this is the same as in gcmd file list. I meant ctime.

How about mtime instead ? Gives you additional feedback for rename success.

> > How about access to intview (F3), in case you like to check if some
> > image file really is what you think it is...yes you can do that in the
> > main window but then have to throw away toe selection.
> 
> Good idea - added to context menu as rev. 2286. I haven't assigned F3,
> as it'd be working only for focused file result.

that's ok. But i don't understand why F3 on focussed (selected) would be wrong. 
I mean, it's just like we are used to how F3 works, no ?

> That's not that easy. Basically speaking - gcmd doesn't know if the
> rename will be successful unless it tries (eg. read-only mounts or file
> systems not case-aware). 

I see your point. Hmmm, let's call the feature i'm proposing rather 'preview 
verification' instead of 'success control'. A virtual success indicator, that 
is.


And i think we don't need to consider any unusual filesystem condition in the 
first place, and there always will be the final result feedback as is.
In case of a readonly filesystem, there should be an error message anyway.
Case-unaware filesystems ? Dunno anyone. Well, some old DOS have filename 
length restriction. But hey you can't always deal with any bordercase.

> Moreover, there even are some renames that
> COULD be perfectly performed, but gcmd can't resolve it automatically,
> like:
> 
>     file1 -> file2
>     file2 -> file3
>     file3 -> file4

That's the reason i like the idea of preview verification. You could for 
example drag and drop around until it works. Another idea is to repeat the 
operation on the failures in a second run, to see if it would work now.

If there's no preview verification, then another thing could be useful: 
Reverting.


> But there is still one question left - what to do AFTER rename? There
> are 3 possible scenarios:

>     3. leave dlg open, update file names in reults list and mark
> failures

Definitely the best choice.

I'm sorry i'm again asking only for features (instead of doing something 
useful); i hope you know i'm ok with anything you can offer, in any way.

greets, micha