ZTree.com  | ZEN  | About...  

 Index   Back

Making it very modular?   [Discuss]

By: Steve Rawling     Sydney  
Date: Jun 20,2002 at 09:13
In Response to: Making it very modular? (Juergen Hestermann)

Though I'm being ignored, I will persevere:)

Your examples can be already done by the existing method after a few bug fixes as I have mentioned above.

In summary the existing method with my proposed "fixes" uses the simple rules
1 if the dot comes last, the F&R strings apply to the name. A * is not necessary after the dot.
2 if the dot comes first, the F&R strings apply to the extention.A * is not necessary before the dot.
3 If there is no dot, the F&R strings apply to both name and extention.
4 Dots which are not separating the name and extention must be preceded by a " otherwise they are not matched.
5 Two dots not preceded by a " gives an error message
6 There is no necessity to refer to CO4H

In detail the existng(+bugfix) F&R does each of your examples as shown in bold as follows.

> "name1"name2"B
\name1\name2\
> and 'name1' includes the period *and* the extension. Otherwise you would be not
> be able to do the following:

> "at.home"at_home"b
\at".home\at_home\

> on these file names:

> at.home.it.is.fine
> at.home.at.home.2000.doc
> we.walk.at.home

> to result in

> at_home.it.is.fine
> at_home.at.home.2000.doc
> we.walk.at_home

> It's not only to get rid of the separator between name and extension. It is just
> for those cases where you don't have *any* extension (at least you don't care
> about them) and where the more or less arbitrarily existing periods are not
> inserted to delimit the name. So you need the ability to completely ignore the
> special nature of the rightmost period and treat it in the same way as all other
> characters. The change of all periods to underscores as in

> "."_"b
\".\_\
> is only a special case here. And if you only want the rightmost period to be
> changed even if there are more of them in some file names you need a modifier to
> restrict the number of changes to 1 as in

> "."_"br1

This is the only example not achievable by the bug fixed existing functionality. Another special code would be needed, say
\"|\_\

This would be a rare need IMO and therefore a case for the external approach using ctrl+B and a text editor.

If you want to discuss future possibilities why not consider options for search string pattern matching such as
"? for any character
"a for any alpha
"d for any numeric
"f for any alphanumeric
"!f for anything except an alphanumeric
"[a,b,c] for a single occurence of either a b or c
" {a,b,c} an optional occurrence of a b or c
"044 for a single occurrence of ascci character 044
"h1b for a single occurence of hex value 1b
"* for multiple occurence of the previous character until the next character is matched
etc
etc
etc

But as I said I dont think ZtreeWin's F&R should bother with these.

An interesting related issue is the possible development of pattern matching in FW ctrl-Search and FW View Find. Is this wanted by anyone. I don't need it- if I need to use anything more compliated than a*b then I go to my text editor. I feel the same about F&R.

And lastly

I propose we call the functionality SR instead of F&R. Then we could have RSR CSR and MSR for its application in Rename, copy and move functions.

Find is more commonly associated with the single task of locating a string.

The & character is unnecessary and as a shifted key is difficult to type.

And besides SR reminds me of someone:)

Steve

1,751 views      
Thread locked
 

Messages in this Thread

 
96,637 Postings in 12,231 Threads, 350 registered users, 68 users online (0 registered, 68 guests)
Index | Admin contact |   Forum Time: Mar 29, 2024 - 12:52 am UTC  |  Hits:62,386,438  (1,224 Today )
RSS Feed