Let the "Remove" rule copy the string from a loaded file

narayan · 2009-03-30 03:41

The Remove rule requires us to enter the string manually. Some of these strings are not standard English words (e.g. "-8fleng", which is often found at the end of flv files). Sometimes the string is very long. Entering them in the rule is both time-consuming and error-prone.

There is a workaround available. However, it is not easy:

Before launching the Remove rule, the user has to do this-
1. Select a file that has the undesired string.
2. Press F2 to enter Manual Edit mode.
3. Select the string with mouse/keyboard.
4. Press CTRL+C.
5. Press ESC to exit the Manual Edit mode.
6. Launch Remove rule.
7. Click inside its box and press CTRL+V.

It would be far easier to pick the string from one of the loaded files.

Suggested scenario: The Remove rule has a "grab" button. It pops up a "grab" window that has a plain-text list of all the loaded files (one file name per line). The user highlights any part of any file and presses OK. The "grab" window closes and the selected string is passed on to the Remove rule.

This will serve well even when the words are easy-to-remember "standard English".

prologician · 2009-03-30 17:12

If the thing is a fixed length (or otherwise marked with a delimiter... as in the - in your example), you could probably delete it using the Delete rule, rather than using the Remove rule. Since we're talking the end of the filename, you'd check the "right to left" box. And either punch in the length, or use that delimiter to mark how far to go to delete.

This way, you don't need to know the exact text of what you're removing, only a single character of it (at most).

narayan · 2009-03-30 17:34

Yes, in special cases we can remove the extra string with other tricks.

But I am thinking only of the cases where the "Remove" rule is the best choice.

BTW the same "Grab" window can be used in the UserInput rule also, where the user first grabs the existing names and then edits any/all of them manually. This effectively converts the UserInput into a Manual multi-line Edit rule. If the user has to clean up a lot of junk in multiple files, and if there is no patterns, then this would be a very good feature. It is not only much faster than using F2 on each file, but it also allows the user to stack the manual edit results with other rules. (Currently the manual edit results cannot be passed on to any other rule.)

(I know this is a separate idea, but I mentioned it in this thread because it uses the same "Grab" window as its key element.)

krtek · 2009-03-30 18:19

The first one (about Remove rule) might be quite useful...

But the second one (about UserInput) won't work. I guess it would need a complete reconstruction of the application. It's because rules are applied file by file (so all the rules for the first filename, then all the rules for the second filename...). There is no point in the process when you would be able to do complex proof-read of all the filenames and then pass it to the next rule.

Now such a thing (only after the full preview) might be achieved by exporting new names to clipboard, pasting them into eg. notepad, editing them and importing back to ReNamer. And if this process might be optimized with some kind of "Grab" window (as you call it) it might be useful, so you could press the button Proof-Reading (or something like that) and you get the window for quick multiline edit of all the filenames.

narayan · 2009-03-31 02:46

Now such a thing (only after the full preview) might be achieved by exporting new names to clipboard, pasting them into eg. notepad, editing them and importing back to ReNamer. And if this process might be optimized with some kind of "Grab" window (as you call it) it might be useful, so you could press the button Proof-Reading (or something like that) and you get the window for quick multiline edit of all the filenames.

Yes, that's what I meant. The "Grab" window will shorten the cycle tremendously.

When the edited names are put back into the UserInput rule, and when the rule is added to ReNamer's rules stack, the Files pane will show preview.

There is no point in the process when you would be able to do complex proof-read of all the filenames and then pass it to the next rule.

Actually THAT's the point: The idea is not to do the whole thing manually. The other rules (e.g. cleanup, case) can still add tremendous value. I generally use F2 to remove some parts of the name; but I remove the -._ characters with the cleanup rule; and then finally use the Case rule. The Grab window will allow me to use the same trick in bulk. But the other rules are still required.

@having to redesign ReNamer:
I don't think so- If the UserInput rule can be used in the middle of the rules stack at present, the addition of the grab window won't change the logic, because ReNamer would be oblivious to how we create the UserInput list --(a) by using the grab window or (b) by manually entering the list or (c) by pasting it from Excel.

Last edited by narayan (2009-03-31 03:02)

krtek · 2009-03-31 20:11

narayan wrote:

I don't think so- If the UserInput rule can be used in the middle of the rules stack at present...

Yes, you can stack the UserInput rule in the middle. But it makes sense only if you use "Insert in front of the filename" or "Insert after current filename" option.
There is no point in using it in the middle with "Replace the current filename" option and that's the only one that might be useful for such middle-process proof-reading.

narayan wrote:

...the addition of the grab window won't change the logic, because ReNamer would be oblivious to how we create the UserInput list

It will change the logic. Now you have to pass the list of filenames/strings to the UserInput rule BEFORE Preview. So this is constant list.
You want to edit it in the middle of the process and that's impossible.

Why?
Let's do it step-by-step.
Three rules, eg.:
1. CleanUp (get rid of "_")
2. UserInput (imaginatory proof-reading)
3. Case (uppercase filename)

Three files:
1. I'm_the--first_file.txt
2. I_m_the_second__file.txt
3. I_am_the_third_file.txt

ReNamer starts with the first file, it cleans it up, it..... shows you your list to edit (with the first filename after cleanup), you make adjustments and ReNamer changes Case for that filename..
Then ReNamer takes the second file, cleans it up, shows you your list (with already done first file, and second file only after cleanup) you make adjustments, and Renamer changes Case... and so on...

There really is no point in the middle of the process to do COMPLEX (for all the files) proof-reading.

narayan · 2009-04-01 15:19

Ok, in which case the UserInput can be used in stand-alone mode, rather than putting it in the middle of rule-stack. (It would be better to use the CleanUp and case rules beforehand, in an independent cycle.)

To sum up, the proposed "grab" window can be useful in two different rules: Remove and UserInput.

den4b Forum

#1 2009-03-30 03:41

Let the "Remove" rule copy the string from a loaded file

#2 2009-03-30 17:12

Re: Let the "Remove" rule copy the string from a loaded file

#3 2009-03-30 17:34

Re: Let the "Remove" rule copy the string from a loaded file

#4 2009-03-30 18:19

Re: Let the "Remove" rule copy the string from a loaded file

#5 2009-03-31 02:46

Re: Let the "Remove" rule copy the string from a loaded file

#6 2009-03-31 20:11

Re: Let the "Remove" rule copy the string from a loaded file

#7 2009-04-01 15:19

Re: Let the "Remove" rule copy the string from a loaded file

Board footer