| ||
On October 26, 1999, I included the following sentence in a posting regarding Find and Replace: 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: 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? 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: 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. 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 | ||
|
Messages in this Thread
- [Discuss] Rename Find and Replace (4,046) - John Gruener - Jun 16,2002 at 11:22 [Discuss]
- [Discuss] Rename Find and Replace (2,203) - Pat Gilbert - Jun 16,2002 at 14:44
- [Discuss] RFR - The Period (1,915) - John Gruener - Jun 17,2002 at 04:25
- [Discuss] RFR - The Period (1,902) - Juergen Hestermann - Jun 17,2002 at 06:59
- [Discuss] RFR - The Period (1,896) - John Gruener - Jun 17,2002 at 11:53
- [Discuss] RFR - The Period (1,918) - Juergen Hestermann - Jun 17,2002 at 17:32
- [Discuss] RFR - The Period (1,911) - Slobodan Vujnovic - Jun 18,2002 at 01:56
- [Discuss] RFR - The Period (1,776) - Juergen Hestermann - Jun 18,2002 at 02:42
- [Discuss] RFR - The Period (1,809) - Slobodan Vujnovic - Jun 18,2002 at 03:05
- [Discuss] RFR - The Period (1,776) - Juergen Hestermann - Jun 18,2002 at 02:42
- [Discuss] RFR - The Period (1,896) - John Gruener - Jun 17,2002 at 11:53
- [Discuss] RFR - The Period (1,902) - Juergen Hestermann - Jun 17,2002 at 06:59
- [Discuss] RFR - Open Parsing (1,990) - John Gruener - Jun 17,2002 at 06:02
- Cart before the horse please (1,784) - Michael Kahn - Jun 17,2002 at 07:19
- Cart before the horse please (1,824) - John Gruener - Jun 17,2002 at 07:55
- Cart before the horse please (1,847) - Jim Farnsworth - Jun 17,2002 at 10:03
- Cart before the horse please (1,803) - Steve Rawling - Jun 17,2002 at 12:19
- Cart before the horse please (1,847) - Jim Farnsworth - Jun 17,2002 at 10:03
- I've accepted LFN's as a fact of life (1,906) - Slobodan Vujnovic - Jun 17,2002 at 19:37
- I've accepted LFN's as a fact of life (1,931) - Michael Kahn - Jun 18,2002 at 06:19
- I've accepted LFN's as a fact of life (1,811) - Jim Farnsworth - Jun 18,2002 at 09:37
- I've accepted LFN's as a fact of life (1,890) - Slobodan Vujnovic - Jun 18,2002 at 23:30
- I've accepted LFN's as a fact of life (1,815) - Jim Farnsworth - Jun 18,2002 at 23:56
- I've accepted LFN's as a fact of life (1,812) - Michael Kahn - Jun 18,2002 at 23:57
- I've accepted LFN's as a fact of life (1,769) - Jim Farnsworth - Jun 19,2002 at 00:06
- I've accepted LFN's as a fact of life (1,890) - Slobodan Vujnovic - Jun 18,2002 at 23:30
- BG (1,827) - Slobodan Vujnovic - Jun 18,2002 at 23:39
- BG (1,760) - Michael Kahn - Jun 19,2002 at 01:12
- I've accepted LFN's as a fact of life (1,811) - Jim Farnsworth - Jun 18,2002 at 09:37
- I've accepted LFN's as a fact of life (1,931) - Michael Kahn - Jun 18,2002 at 06:19
- Cart before the horse please (1,824) - John Gruener - Jun 17,2002 at 07:55
- Cart before the horse please (1,784) - Michael Kahn - Jun 17,2002 at 07:19
- [Discuss] RFR - The Period (1,915) - John Gruener - Jun 17,2002 at 04:25
- [Discuss] Rename Find and Replace (1,826) - Steve Rawling - Jun 16,2002 at 15:29
- [Discuss] RFR - The Period (1,866) - John Gruener - Jun 17,2002 at 04:36
- [Discuss] RFR - The Period (1,791) - Steve Rawling - Jun 17,2002 at 07:14
- [Discuss] RFR - The Period (1,866) - John Gruener - Jun 17,2002 at 04:36
- [Discuss] Rename Find and Replace (1,877) - Juergen Hestermann - Jun 16,2002 at 20:34
- [Discuss] RFR - Case Sensitivity (1,939) - John Gruener - Jun 17,2002 at 07:06
- [Discuss] RFR - Replacement Sequence (1,774) - John Gruener - Jun 17,2002 at 12:13
- [Discuss] Rename Find and Replace (1,592) - Jim Farnsworth - Jun 16,2002 at 23:48
- [Opinion] Most Important Missing Capability (1,743) - John Gruener - Jun 18,2002 at 00:44
- [Opinion] Most Important Missing Capability (1,779) - Kim Henkel - Jun 18,2002 at 00:47
- pretty much agree with that one [no msg] (1,783) - Jim Farnsworth - Jun 18,2002 at 01:29
- I also agree [no msg/no dot] (1,740) - Michael Kahn - Jun 18,2002 at 02:19
- [Opinion] Most Important Missing Capability (1,743) - John Gruener - Jun 18,2002 at 00:44
- Cart before the horse please (1,874) - David Wall - Jun 17,2002 at 08:03
- Cart before the horse please (1,793) - John Gruener - Jun 17,2002 at 08:13
- Cart before the horse please (1,698) - Slobodan Vujnovic - Jun 17,2002 at 20:20
- Not easy... (1,903) - Slobodan Vujnovic - Jun 18,2002 at 08:29
- Not easy but Some examples (2,138) - Steve Rawling - Jun 18,2002 at 11:15
- Possible solution (1,941) - Juergen Hestermann - Jun 18,2002 at 18:02
- Very nice! (1,871) - Slobodan Vujnovic - Jun 18,2002 at 22:58
- Possible solution (2,005) - Steve Rawling - Jun 19,2002 at 12:48
- Very light-weight for today's needs (1,895) - Slobodan Vujnovic - Jun 18,2002 at 20:56
- [Discuss] RFR - Making Progress (1,836) - John Gruener - Jun 19,2002 at 04:19
- [Discuss] RFR - Making Progress (1,976) - Juergen Hestermann - Jun 19,2002 at 06:56
- [Discuss] RFR - Making Progress (1,761) - John Gruener - Jun 19,2002 at 07:25
- Regex (1,732) - Steve Rawling - Jun 19,2002 at 09:34
- Making it very modular? (1,808) - Slobodan Vujnovic - Jun 20,2002 at 02:53
- Agree, that makes sense. (1,761) - Jim Farnsworth - Jun 20,2002 at 03:35
- Making it very modular? (1,670) - Steve Rawling - Jun 20,2002 at 07:21
- Simple design, complex application (1,804) - Slobodan Vujnovic - Jun 20,2002 at 20:15
- Simple design, complex application (1,803) - Steve Rawling - Jun 20,2002 at 21:37
- dir\file = name.ext similarity (1,779) - Slobodan Vujnovic - Jun 20,2002 at 22:44
- dir\file = name.ext would add confusion. (1,755) - Steve Rawling - Jun 21,2002 at 09:03
- RFR - Rename Mask Command? (1,553) - John Gruener - Jun 21,2002 at 09:45
- RFR - Rename Mask Command? (1,590) - Steve Rawling - Jun 21,2002 at 09:57
- dir\file = name.ext would add confusion. (1,647) - Juergen Hestermann - Jun 21,2002 at 17:19
- RFR - Rename Mask Command? (1,553) - John Gruener - Jun 21,2002 at 09:45
- dir\file = name.ext would add confusion. (1,755) - Steve Rawling - Jun 21,2002 at 09:03
- dir\file = name.ext similarity (1,779) - Slobodan Vujnovic - Jun 20,2002 at 22:44
- Simple design, complex application (1,461) - Juergen Hestermann - Jun 21,2002 at 02:38
- Simple design, complex application (1,557) - Steve Rawling - Jun 21,2002 at 11:07
- Simple design, complex application (1,606) - Juergen Hestermann - Jun 21,2002 at 17:19
- Simple design, simple maintenance (1,688) - Slobodan Vujnovic - Jun 21,2002 at 18:25
- Simple design, simple maintenance (1,628) - Steve Rawling - Jun 24,2002 at 17:11
- Simple design, simple maintenance (1,569) - Slobodan Vujnovic - Jun 24,2002 at 18:33
- Simple design, simple maintenance (1,530) - Michael Kahn - Jun 25,2002 at 00:43
- Simple design, simple maintenance (1,569) - Slobodan Vujnovic - Jun 24,2002 at 18:33
- Simple design, simple maintenance (1,628) - Steve Rawling - Jun 24,2002 at 17:11
- Simple design, complex application (1,557) - Steve Rawling - Jun 21,2002 at 11:07
- Simple design, complex application (1,803) - Steve Rawling - Jun 20,2002 at 21:37
- Simple design, complex application (1,804) - Slobodan Vujnovic - Jun 20,2002 at 20:15
- Making it very modular? (1,751) - Juergen Hestermann - Jun 20,2002 at 07:47
- Making it very modular? (1,752) - Steve Rawling - Jun 20,2002 at 09:13
- Making it very modular? (1,588) - Juergen Hestermann - Jun 20,2002 at 17:25
- Making it very modular? (1,627) - Slobodan Vujnovic - Jun 20,2002 at 20:36
- Making it very modular? (1,626) - John Gruener - Jun 20,2002 at 10:35
- Making it very modular? (1,589) - Juergen Hestermann - Jun 20,2002 at 17:04
- Keeping the language simple a valid goal (1,700) - Slobodan Vujnovic - Jun 20,2002 at 20:46
- Keeping the language simple a valid goal (1,620) - Steve Rawling - Jun 20,2002 at 21:48
- RFR - Ambiguity (1,530) - John Gruener - Jun 21,2002 at 00:18
- RFR - Ambiguity (1,598) - Slobodan Vujnovic - Jun 21,2002 at 00:52
- RFR - Ambiguity (1,658) - Steve Rawling - Jun 21,2002 at 08:32
- RFR - Ambiguity (1,602) - John Gruener - Jun 21,2002 at 09:21
- RFR - Ambiguity (1,808) - Steve Rawling - Jun 21,2002 at 09:52
- RFR - Ambiguity (1,565) - Juergen Hestermann - Jun 21,2002 at 17:19
- RFR - .Ambiguity (1,670) - Steve Rawling - Jun 22,2002 at 16:40
- RFR - .Ambiguity (1,801) - Juergen Hestermann - Jun 22,2002 at 18:04
- RFR - .Ambiguity (1,639) - Steve Rawling - Jun 24,2002 at 11:52
- RFR - .Ambiguity (1,930) - Juergen Hestermann - Jun 25,2002 at 05:07
- RFR - .Ambiguity (1,932) - Steve Rawling - Jun 25,2002 at 08:39
- RFR - My fault (1,513) - Graeme Hoose - Jun 27,2002 at 02:40
- Deleting posts in the middle of a thread (1,610) - Steve Rawling - Jun 29,2002 at 15:40
- Deleting posts in the middle of a thread (1,727) - Graeme Hoose - Jun 29,2002 at 22:45
- Deleting posts in the middle of a thread (1,610) - Steve Rawling - Jun 29,2002 at 15:40
- RFR - My fault (1,513) - Graeme Hoose - Jun 27,2002 at 02:40
- More hard facts :-) (1,636) - Slobodan Vujnovic - Jun 25,2002 at 23:13
- More hard facts :-) (1,656) - Michael Kahn - Jun 26,2002 at 00:12
- More hard facts :-) (1,661) - Juergen Hestermann - Jun 26,2002 at 04:43
- far out and solid(dot) (1,470) - Steve Rawling - Jun 26,2002 at 09:01
- RFR - .Ambiguity (1,932) - Steve Rawling - Jun 25,2002 at 08:39
- RFR - .Ambiguity (1,801) - Juergen Hestermann - Jun 22,2002 at 18:04
- RFR - .Ambiguity (1,670) - Steve Rawling - Jun 22,2002 at 16:40
- RFR - Ambiguity (1,602) - John Gruener - Jun 21,2002 at 09:21
- RFR - Ambiguity (1,530) - John Gruener - Jun 21,2002 at 00:18
- Keeping the language simple a valid goal (1,620) - Steve Rawling - Jun 20,2002 at 21:48
- Keeping the language simple a valid goal (1,700) - Slobodan Vujnovic - Jun 20,2002 at 20:46
- Making it very modular? (1,589) - Juergen Hestermann - Jun 20,2002 at 17:04
- Making it very modular? (1,560) - Slobodan Vujnovic - Jun 20,2002 at 20:29
- Making it very modular? (1,580) - Juergen Hestermann - Jun 21,2002 at 02:26
- Making it very modular? (1,752) - Steve Rawling - Jun 20,2002 at 09:13
- RFR - More Progress (1,780) - John Gruener - Jun 20,2002 at 10:14
- RFR - More Progress (1,675) - Steve Rawling - Jun 20,2002 at 10:49
- RFR - More Progress (1,788) - John Gruener - Jun 20,2002 at 11:39
- RFR - More Progress (1,631) - Steve Rawling - Jun 20,2002 at 12:03
- RFR - Words (1,558) - John Gruener - Jun 21,2002 at 00:42
- RFR - Words (1,548) - Steve Rawling - Jun 21,2002 at 09:36
- RFR - Pattern Matching (1,521) - John Gruener - Jun 21,2002 at 10:10
- RFR - Pattern Matching (1,713) - Jim Farnsworth - Jun 21,2002 at 10:52
- RFR - Pattern Matching (1,767) - Steve Rawling - Jun 21,2002 at 11:01
- RFR - Pattern Matching (1,521) - John Gruener - Jun 21,2002 at 10:10
- RFR - Words (1,548) - Steve Rawling - Jun 21,2002 at 09:36
- RFR - Words (1,558) - John Gruener - Jun 21,2002 at 00:42
- RFR - More Progress (1,631) - Steve Rawling - Jun 20,2002 at 12:03
- RFR - More Progress (1,788) - John Gruener - Jun 20,2002 at 11:39
- RFR - More Progress (1,675) - Steve Rawling - Jun 20,2002 at 10:49
- Example #2 (1,611) - Slobodan Vujnovic - Jun 20,2002 at 23:14
- [Discuss] RFR - Making Progress (1,976) - Juergen Hestermann - Jun 19,2002 at 06:56
- Example #1 (1,603) - Slobodan Vujnovic - Jun 20,2002 at 22:13
- RFR - The Command Separator (1,763) - John Gruener - Jun 21,2002 at 01:48
- RFR - The Command Separator (1,667) - Slobodan Vujnovic - Jun 21,2002 at 02:21
- RFR - Operator Command Summary (1,683) - John Gruener - Jun 21,2002 at 02:46
- Ignore mimic not clear (1,611) - Slobodan Vujnovic - Jun 21,2002 at 19:09
- RFR - Mimic or Not? (1,545) - John Gruener - Jun 22,2002 at 06:43
- Ignore mimic not clear (1,611) - Slobodan Vujnovic - Jun 21,2002 at 19:09
- RFR - Changing Case (1,547) - John Gruener - Jun 24,2002 at 00:44
- RFR - Changing Case (1,461) - Michael Kahn - Jun 24,2002 at 06:22
- RFR - Changing Case (1,718) - John Gruener - Jun 24,2002 at 06:43
- RFR - Changing Case (1,638) - Michael Kahn - Jun 24,2002 at 07:49
- RFR - Changing Case (1,554) - John Gruener - Jun 24,2002 at 09:15
- RFR - Changing Case (1,649) - Michael Kahn - Jun 24,2002 at 09:29
- RFR - Changing Case (1,609) - John Gruener - Jun 24,2002 at 09:45
- RFR - Changing Case (1,649) - Michael Kahn - Jun 24,2002 at 09:29
- RFR - Changing Case (1,554) - John Gruener - Jun 24,2002 at 09:15
- RFR - Changing Case (1,638) - Michael Kahn - Jun 24,2002 at 07:49
- RFR - Changing Case (1,557) - Juergen Hestermann - Jun 24,2002 at 07:11
- RFR - Changing Case (1,718) - John Gruener - Jun 24,2002 at 06:43
- RFR - Changing Case (1,461) - Michael Kahn - Jun 24,2002 at 06:22
- RFR - Wildcards (1,873) - John Gruener - Jun 24,2002 at 07:33
- RFR - Wildcards (1,970) - Steve Rawling - Jun 24,2002 at 09:53
- Rule #5 needs to sink in (1,620) - Slobodan Vujnovic - Jun 27,2002 at 01:42
- Please read the release notes ;-) (1,574) - Kim Henkel - Jun 27,2002 at 01:46
- It's the theoretical part (1,697) - Slobodan Vujnovic - Jun 27,2002 at 02:11
- The "Theoretical" Part - It's Not Rule 5 (1,992) - John Gruener - Jun 27,2002 at 03:09
- The "Theoretical" Part - It's Not Ru (1,596) - Slobodan Vujnovic - Jun 28,2002 at 00:18
- Please read the release notes ;-) (1,574) - Kim Henkel - Jun 27,2002 at 01:46
- RFR - Summary Here (1,516) - John Gruener - Jun 26,2002 at 05:02
- [Discuss] Rename Find and Replace (2,203) - Pat Gilbert - Jun 16,2002 at 14:44