New Swap or Rearrange rule

krtek · 2009-08-30 09:04

Stefan's example:

New Order: $1$2vacation$22009$2$3

made me think about one test of the Rearrange rule.
I'm not sure if I shouldn't post it as a bug (but as I get 50% of mistakes on the bugs forum, I'll better not ).

Thesis:
It's not $1..$N.
It's $1..$9.
The rule splits the filename into infinite number of parts, but it allows to reuse only 9 (18 if use both $1 and $-1) of them.

Proof:
FileName: "0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20-21-22-23-24-25-26-27-28-29-30"
Delimiter: -
New Order: "Number 22 = $22" ($22 part contains "21")

Result: "Number 22 = 12"

Possible solutions:
* Changing format from $n to ${n} or something similar (this also solves the need of escaping $).
* Changing format from $n to {n}. (then need to escape {,}).
* Changing format from $n to $n, $$nn, $$$nnn and so on...

Last edited by krtek (2009-08-30 09:11)

den4b · 2009-09-06 20:41

Well spotted, krtek!

For some unknown for me reason I was substituting $1..$N starting from the smallest, i.e. $1, $2, $3, etc. So for $11 it would substitute $1 before the counter reached $11. The fix was to simply start substituting from the highest index, i.e. $N, $N-1, ... $3, $2, $1. I am surprised I missed this one...

As of $22009 problem, we should just be aware of it. I don't want to change the format.

Stefan · 2009-09-29 08:36

den4b wrote:

[...]
There is only one thing that keeps bothering me regarding this option: What to do if option is SELECTED and some intermediate delimiter is NOT found? (a) Continue with the next delimiter or (b) finish splitting because the order of delimiters is broken?
To highlight the problem, imagine input "abc , def - ghi" and split by ",|+|-"
(a): $1=abc $2=def $3=ghi ("+" was skipped because not found)
(b): $1=abc $2=def - ghi (search terminated because "+" was not found)

I want to remind on this behaviour!

FROM: ThisIsADJExample
TO: ThisIs AD JExample (at least the wanted result)

Delimiter: dj (wrong case is not found, which is an feature!)
New Order: $1 DJ $2

Results in: ThisIsADJExample dj

I know this is not the best example, but if user didn't use an correct delimiter it gives bad results.
So i think the search should be terminated if delimiter is not found. Not the delimiter skipped only.
Because in a long list of files i wouldn't see it that there was an problem.

-----------------------------

Stefan wrote:
After playing around a bit with the examples at http://www.den4b.com/wiki/ReNamer:Rules:Rearrange
i see now the use of an option like "[ ] Delimiters to token" would be useful sometimes.
krtek wrote:
I can't see when it really would be useful. For me it's neither of your examples.

"[ ] Delimiters to token" to reuse the delimiter as $n
would be useful too for reusing the rule
without modifying the 'New Order'

Last edited by Stefan (2009-09-29 08:37)

krtek · 2009-09-29 08:41

Stefan wrote:

"[ ] Delimiters to token" to reuse the delimiter as $n
would be useful too for reusing the rule
without modifying the 'New Order'

Got me. I haven't thought about that. That's probably the ONE.

den4b · 2009-10-13 20:52

den4b wrote:

There is only one thing that keeps bothering me regarding this option: What to do if option is SELECTED and some intermediate delimiter is NOT found? (a) Continue with the next delimiter or (b) finish splitting because the order of delimiters is broken?
To highlight the problem, imagine input "abc , def - ghi" and split by ",|+|-"
(a): $1=abc $2=def $3=ghi ("+" was skipped because not found)
(b): $1=abc $2=def - ghi (search terminated because "+" was not found)

I have revised this thought and came to a conclusion that it is better to play safe than to be sorry. As somebody has pointed out before, when exact order of delimiters is used and one of the delimiters is not found the whole operation should be terminated (meaning no change to the name by that rule). This logic should minimize the possibility of silently loosing parts of the filename.

I have also changed "Exact order of delimiters" checkbox into one of the "Split by" radio buttons, which is now called "Pattern of delimiters". It seems like a better alternative.

I think this is the final revision of this rule. I want to wrap it up for the new release.

Can you guys run few tests on this rule, testing functionality and logic?
ReNamerBeta.zip

krtek · 2009-10-13 21:11

First tests look fine.
The idea of "Pattern of delimiters" as the radio button is definetely the best solution.
I'm just wondering if not change the name to "Exact pattern of delimiters". Just to emphasise the meaning, and help newbie see, how it is different from the "delimiters" without looking into manual.

Last edited by krtek (2009-10-14 15:48)

Stefan · 2009-10-14 09:55

Putting this option in that row makes sense to me (use this, or this, or that)

But with this naming "Pattern of delimiters" i can't guess what is does.

My proposition would go to:
Split using: ( )Delimiters [x] Force sequence __ (o)Positions

where 'Force sequence' is grayed out as long as 'Delimiters' is not checked.

And 'Strip extension' is mostly on the right side of an dialog, makes sense to have them everywhere on the same place.

Will test the function itself if i find some free time.
Thanks for the update Denis.

narayan · 2009-10-14 11:59

Stefan, would you kindly put up the latest logic and some good examples of this option?

I'll need a clear idea for the manual.

Thanks in advance!

krtek · 2009-10-14 15:55

narayan, let's wait for the dialog to settle.

Denis, what would you say about some version information?
Sometimes it's hard to determine which beta is the newest one...

Last edited by krtek (2009-10-14 15:55)

den4b · 2009-10-14 20:09

"[x] Force sequence" is exactly like it was before, except different wording of it. The radio button seems to be a much better option.

"Exact pattern of delimiters" might sound more strict, but isn't that implied by a word "pattern" ? There is also a shortage of space to insert the word "exact", I tried it! (also consider space for translations)

krtek, I will try to follow that per-beta version information approach after the coming release...

den4b Forum

#71 2009-08-30 09:04

Re: New Swap or Rearrange rule

#72 2009-09-06 20:41

Re: New Swap or Rearrange rule

#73 2009-09-29 08:36

Re: New Swap or Rearrange rule

#74 2009-09-29 08:41

Re: New Swap or Rearrange rule

#75 2009-10-13 20:52

Re: New Swap or Rearrange rule

#76 2009-10-13 21:11

Re: New Swap or Rearrange rule

#77 2009-10-14 09:55

Re: New Swap or Rearrange rule

#78 2009-10-14 11:59

Re: New Swap or Rearrange rule

#79 2009-10-14 15:55

Re: New Swap or Rearrange rule

#80 2009-10-14 20:09

Re: New Swap or Rearrange rule

Board footer