ZTree.com  | ZEN  | About...  

 Index   Back

[Discuss] RFR - Making Progress   [Discuss]

By: Juergen Hestermann       
Date: Jun 19,2002 at 06:56
In Response to: [Discuss] RFR - Making Progress (John Gruener)

> Replacing the Extension Period
> ------------------------------ The suggested format of a blank Find string to
> indicate the extension period is another good one. With a multiple F&R string
> capability, virtually any result could be achieved in one command. Again, this
> would not have to be implemented initially, but could be planned for the future.

I think this is not so intuitive to use. I would suggest two new modifiers which would help doing this more directly and also would be of use in other cases:

L# - Replace # occurences from the left
R# - Replace # occurences from the right

They would mostly be used with #=1 but maybe used with higher numbers too. Cause I would prefer not to separate operators and modifiers the replacement of the rightmost dot with an underscore would look like this then:

"."_"br1

The 'b' indicates that I want to consider the whole file name (including dot and extension) and that I want to search and replace 1 "." from the 'r'ight by "_".

> Wildcards
> --------- I agree that the '?' wildcard would not have to be supported
> initially, but I think it should be at least planned for the future. I would
> like to make it part of the 'rules', but leave it to Kim as to when he might add
> support for it.

It will probably not be so very hard to implement but if the time is not available now it can wait because it is not essential, just an addition.

> The '*' wildcard should also be supported for the same reason, to operate on
> *all* characters preceding or following a match, or between two matches.

Yes.

> Operators and Modifiers
> ----------------------- I am not very much in favor of having Operators in
> front of the string, and Modifiers after it. The operators can work just as well
> if they all follow the string. The 'command' should be the leading double quote,
> IMO.

At first I favoured the operators and modifiers on the left but now I think it is better on the right. The main things are the two strings which should come first.

> Reasons:
> 2. Multiple F&R strings won't have Modifiers immediately followed by Operators,
> and the need to delimit them.

I would like to force all operators and modifiers tight together without any spaces between them so that one (or more) spaces clearly delimit a F&R command.

> 3. Appearance in Rename history makes these easily recognized.
> (The last point is not an issue if Kim decides to separate the RFR history from
> Rename, but the other two are still valid, I think.)

I am still not sure whether it will be possible to merge F&R rename and the normal rename. I need some examples of how this would look like and what syntax should be used then. At least the normal rename needs to be wrapped in double quotes too. This would break the strong rule that in F&R there are *always* three double quotes (optionaly followed by operators/modifiers) which make up one command. This makes the coding harder. And the case changing options have to be coded by modifiers too.

> F&R Words and Case
> ------------------ Adding a 'W' operator is another good idea. I consider this
> to be advanced and not necessary initially, but again could be planned in the
> 'rules'.

Yes.

> As for using 'U' rather than 'C' to indicate case sensitivity, I disagree. 'U'
> indicates 'uppercase', while 'C' indicates 'observe Case', whether it's upper or
> lower.

It was just the option that the old wordstar-compatible editors used. I never thought about the meaning. So let's take 'C'.

> - John

Jürgen.

1,977 views      
Thread locked
 

Messages in this Thread

 
96,637 Postings in 12,231 Threads, 350 registered users, 116 users online (0 registered, 116 guests)
Index | Admin contact |   Forum Time: Mar 29, 2024 - 3:19 pm UTC  |  Hits:62,410,694  (25,480 Today )
RSS Feed