ZTree.com  | ZEN  | About...  

 Index   Back

RFR - More Progress   [Discuss]

By: John Gruener     Orlando, Florida  
Date: Jun 20,2002 at 11:39
In Response to: RFR - More Progress (Steve Rawling)

> Why bother, John - just keep rename as it is and use a macro to carry out
> multiple RFR's and/or basic Renames.

I think we should be able to store a complete Rename operation on a single history line, without resorting to macros.

> Again this problem does not arise if the existing functionality is maintained
> and macros are used for multiple renames. As I have said some bugs need to be
> fixed thats all.

I, (and I think Jürgen and Slobodan agree), would like to keep the command as simple as possible, because most of the time all most users will want to do is replace one character with another in the Name section only.

Adding simple operators to indicate that more than the name section is targeted seems like a straightforward solution, and easily understood, with no confusion about what happens to the extension period.

Then adding the ability to string several F&R commands together affords almost unlimited F&R capabilities. To be able to combine them with Rename Mask commands would be a bonus, but I still have a problem with finding a good separator character for that.

> IMO, You would be better off spending your time thinking about pattern matching.

I'm open to all suggestions, Steve. When I see *anyone's* suggestion that looks simple and powerful, I'll certainly "spend time thinking about" it, thank you.

> Why is it a worthy goal? we have macros for repeat performances!

Not as simple as retrieving lines in history, IMHO.

> JH> In this light, it almost becomes irrelevant if we implement an operator that
> JH> works on BOTH name and ext, or have two "primitive" ones that work on
> JH> each part -- I'm now in favor of the "primitive" ones, for example,
> JH> because I can always do:
> JH> "name1"name2"N (SEPARATOR) "ext1"ext2"E
> JH> instead of a high-tech
> JH> "name1.ext1"name2.ext2"B

> High tech! are you guys off your rockers or what? Whats high tech about -
> \name1.ext1\name2.ext2\

Well, perhaps Slobodan exaggerated some, and I went along with it. The point is it's more complex for simple operations than it needs to be.

> the current functionality handles these issues without these operators
> A special character is needed for this last period of a string, thats all, say
> "|

As I said before, I'd really like to reserve this character for a future 'find any' function, as in "|abc|"x" means find either a or b or c and replace any of them with x.

> Whats wrong with the existing Rename case options via TAB. Give me an example
> when this would be useful

I think I also explained that one.

Once moTab is used for *changing* case, and would have *no* effect on *finding* both 'a' and 'A' with a Find string of 'a'. Besides, even if it did, it could not easily be saved on a history line.

> W - Whole words only
>
> Again, I'd like to see an example when this is needed- especially without
> pattern matching or wildcards. I would have though this would be well handled by
> not including a space in the search string!

A "Word" is defined as any string surrounded by *any* special characters: space, underscore, period, comma, ampersand, etc, etc. Quite useful I think.

Also, I'm not sure what you mean "without pattern matching". The F&R string "this"that" replaces the pattern "this" with "that". Is this not "pattern matching"?

> I dont think there is any progress so far.

And with this I sincerely disagree Steve.

- John

1,787 views      
Thread locked
 

Messages in this Thread

 
96,637 Postings in 12,231 Threads, 350 registered users, 87 users online (1 registered, 86 guests)
Index | Admin contact |   Forum Time: Mar 29, 2024 - 2:02 am UTC  |  Hits:62,388,123  (2,909 Today )
RSS Feed