ZTree.com  | ZEN  | About...  

 Index   Back

[Discuss] Rename Find and Replace   [Discuss]

By: John Gruener     Orlando, Florida  
Date: Jun 16,2002 at 11:22


Wow! Rename F&R!

On October 26, 1999, I included the following sentence in a posting regarding Find and Replace:
"This has been one of the longest running requests on record."

I believe this is the second most important missing capability in ZTree.

I called this subject [Discuss], rather than [ZEP], because I'd like to encourage some feedback before the final Rename F&R (RFR) rules are set. The larger the menu of ideas available for Kim to pick from, the better will be the final result, IMHO. Also, stating agreement with ideas is also just as important as finding problems with them.

This first implementation of RFR was done quickly to meet a need. As a result, however, I find in testing it I am crashing ZTree often. This might be expected in such an early implementation of such a powerful tool, which has received very little testing up to this point. It is, in any case, certainly a good start, and one to build upon!

There are several issues I would now like to address. I spent a good bit of time on this in 1999, and some very long and tedious discussions with Walter Rassbach on the subject.

I will not bore you with repeated links to these, but if you are interested, and have a couple of hours to spend on it, they are mostly in this thread:
http://www.ztw3.com/forum/forum_entry.php?id=3615

As I see it, the following are the major issues regarding any RFR implementation:

1. Should RFR use a prompted approach, or a self-contained-string approach?
2. If string, should it be capable of being embedded in the Rename Mask?
3. If string, what character should be chosen to indicate and delimit the F&R operation?
4. If string, should it use open parsing, or a closed template approach?
5. If string and closed, how many delimiting characters should be permitted or required?
6. If string, how do we handle the period?
7. If string, do we permit limiting the replacements, and if so, what should be the default limit?
8. If string, should the strings be case sensitive?
9. What characters and lengths do we permit in the Find and Replace strings?

The following are my opinions on these issues.

1. Should RFR use a prompted approach, or a self-contained-string approach?

The advantage of a prompted approach is ease of use, and avoidance of errors. In effect, questions 2, 3, 4, 5, 6, 7 and 8 would be easily solved through the use of prompts and associated function keys.

The primary disadvantage of the prompted approach is the inability to easily save an operation in history. This is a *big* disadvantage, and is reason enough for me to favor the self-contained-string approach currently being implemented.

Of course, another disadvantage would be the time and effort required to design, write and debug a prompted approach.

2. Should it be capable of being embedded in the Rename Mask?

Ideally, this would be very nice. Walter fought hard for this capability.

My feeling is it would make the Rename Mask just too difficult to understand when the F&R part is included, so I prefer a separate operation, again as is being implemented.

3. What character should be chosen to indicate and delimit the F&R operation?

If we restrict ourselves to only the ASCII characters available from the keyboard, there are only three which are not valid naming characters, and not already used in the Rename Mask. They a\ | ".

Walter had suggested that we don't really need to restrict ourselves to these three, since any special key could be used, like a Ctrl/Alt-key or function key, which would insert a special "glyph" in the string. This would be very similar to the glyphs inserted in Filespec by Alt-[ and Alt-].

Personally I don't like that, unless in the future it becomes absolutely necessary because we've run out of ASCII characters for some additional function.

I would like to reserve the | character for an advanced feature which would find all occurrences of several characters, or a range of characters, to be substituted. Example: |ABC| looks for either A or B or C and replaces it with the replacement character or string. (In fact I would prefer that this character be used in Filespec as well for this function, but that's another subject).

This leaves only two remaining. Personally I prefer the double quote for this, because I think it has less chance of being used by mistake instead of the forward slash to do a deletion.

Also, Walter used the backslash in his open parsing examples. We might one day want to consider this type of parsing, and I certainly feel the backslash would be better than the double quote for that. Perhaps the only downside of the double quotes is that some might say they do not 'look' as clean as the backslash.

It would also mean that, in order to avoid confusion, I will need to remove the double quotes from the Rename mask examples in the help file. This I would do.

4. Should it use open parsing, or a closed template approach?

As mentioned above, Walter had proposed an open parsing approach. Frankly, I found this approach difficult to understand, and I think most ZTree users would have the same problem.

However, I think we should be open to considering this in the future, once a clear explanation can be given for how this should work. I don't think there is any reason why both approaches cannot coexist, as long as different delimiters or operators are used. I still have some questions about how such an 'already established' approach works.

In the above mentioned thread, Kim posed this question to Michael:
http://www.ztw3.com/forum/forum_entry.php?id=3716
Michael did not (publicly) reply. It would be nice to see some examples, ...Michael?

5. How many delimiting characters should be permitted or required?

In my 1999 examples I allowed two, three or four delimiters, depending on the need to enclose spaces. I agree now, however, that always requiring exactly three delimiters, regardless of the content of the strings, is the best and cleanest approach. This is how it is currently being implemented.

6. How do we handle the period?

This becomes the stickiest problem of the string approach. Ideally it would be nice to have the same rule for the F&R strings and the Rename Mask, to always separate the name and extension sections with a period. If only one exists, then it represents the extension period.

However, this obviously leads to some cumbersome and ambiguous strings when one wants to find and replace periods, which might be a common need. Using still another character to represent the extension period, as in Spell Search, is also less than satisfactory.

The solution, I think, is to follow the strings, (after the third delimiter), with an operator that signifies whether or not the extension should be included. For example, (using double quotes): "A"B" E would say replace all 'A's with 'B's in only the Extension section of the name. If no operator is present, (or 'N' is used), then only the Name section would be targeted. If both sections should be targeted, then perhaps use either 'NE' or 'B' as an operator. (I prefer 'B' for 'Both', in order to keep it to one letter). Either upper or lower case should be permitted.

This then avoids the necessity of always specifying the extension period. In fact, it will *never* be specified in the strings, making it a lot simpler.

It does have the drawback of not being able to perform two different kinds of replacements on the name and extension sections in the same operation, as can be done with the current implementation. However, I feel this a minor drawback.

With this approach, in a filename, the period separating the name and extension section will never be considered to be a match for a period specified in the Find section, nor can a period in the Replace string ever create a new extension. This also means if the 'E' or 'B' operator is used, it will be invalid to have a period in either section of the F&R string.

7. Do we permit limiting the replacements, and if so, what should be the default limit?

Walter stated that most other F&R functions by default limit the replacements to only one occurrence in any one name. That would require a special operator to indicate multiple occurrences in a name.

My feeling is that most folks will usually want to replace *all* occurrences in a name, so this should be the default, even if it is not the 'safest' approach. A numeric operator following the Replace string would limit the replacements to that number of occurrences in any one name.

8. Should the strings be case sensitive?

I think by default the Find string should not be case sensitive, and Replace should use the same case as the characters being replaced.

This can, however, get complicated if the 'found' string has mixed case, and especially if we allow the Replace string to be longer than the Find. There will be no perfect answer for this, so we'll need to come up with some simple rules to define how this should work.

This could also be somewhat controlled by operators following the string. For example, if 'C' is specified, both Find and Replace would be case sensitive, (force the case of both).

9. What characters and lengths do we permit in the Find and Replace strings?

This final question is the most complex, and most important, in the design decisions.

I'd like to think of the Replace string as operating on the Find string as a Rename mask would operate on a filename. In other words, consider the Find string as being the entire name for purposes of applying the Replace (Rename) mask.

This raises several issues, however, not the least of which is what to do with insufficient characters, excess characters, insertion symbols, deletion symbols, and wildcards.

Here's what I think should be done:

Permit the strings to be different lengths, and permit wildcards. This provides an inherent deletion and insertion capability, without needing the '/' to delete, and the 'less/greater-than' symbols to insert. For example:

"a"" - Deletes all 'a's.
"?a"a" - Deletes any single character preceding an 'a'.
"ab"a" - Deletes any 'b' following an 'a'.
"a"ab" - Inserts a 'b' after every 'a'.
"a*c"x" - Replaces all 'a*c' strings, regardless of length, with the single character 'x'.

This means we can make the insertion and deletion characters invalid in F&R strings, greatly simplifying the syntax, and the coding effort.

The use of wildcards can lead to problems if one is not careful. For example, "?"A" would replace *every* character with an 'A', which is probably something we should not allow. There should be a rule then that states that wildcards may never be used alone in either section of the F&R string.

There are other 'rules' which need to developed and stated. It is difficult to write code and debug something if the rules of operation are not clear. Hopefully we will get some feedback here on this, and I will then post a set of proposed 'Rename Find and Replace Rules', as I did when we were developing Rename.

The most important objective in this RFR development is to be sure we are not overlooking a basic operation which would be difficult or impossible to do using the rules. There are certainly additional capabilities one could wish for, such as "named chunks," (as Walter called them), which would allow repositioning strings in a name. However, I don't consider that kind of operation to be "basic".

What we are looking for here is flaws in the design. For example, can anyone give a good reason and example of why eliminating the '/' and 'less/greater-than' symbols restricts the F&R capabilities?

Another important objective is to not create rules that would make it difficult to expand on them in the future.

Let's "discuss". ;-)

- John

4,046 views      
Thread locked
 

Messages in this Thread

 
96,637 Postings in 12,231 Threads, 350 registered users, 83 users online (0 registered, 83 guests)
Index | Admin contact |   Forum Time: Mar 29, 2024 - 11:21 am UTC  |  Hits:62,403,461  (18,247 Today )
RSS Feed