Recognize periods as word breaks

[admin]

So what happend when combinations of these occur in a set, as in "M$ - fix #123765"? Does it get considered as one break? So that, for now, the "$ - " isn't treated as four breaks...

As four breaks currently. Hmmm, I should change this maybe...

Well, what I was originally envisioning was something like this:


If we're starting from the left side and hit Ctrl-<Right>, the cursor would stop before the next non-break character that occurs after a break character. This would have prevented the behavior j.c. brought up.

The current behavior is Windows standard AFAIK.

[Mesh]

If we're starting from the left side and hit Ctrl-<Right>, the cursor would stop before the next non-break character that occurs after a break character. This would have prevented the behavior j.c. brought up.

The current behavior is Windows standard AFAIK.

Not quite. With the file name "M$ - Test File.txt", XY makes the following stops (cursor stops are right after each line's text):


M$
M$<space>
M$<space>-
M$<space>-<space>



Windows Explorer makes only two stops:

M$<space>
M$<space>-<space>


Basically, Windows Explorer follows the logic I outlined, except that it considers a hyphen a non-break character.

[admin]

With the file name "M$ - Test File.txt", XY makes the following stops (cursor stops are right after each line's text):


M$
M$<space>
M$<space>-
M$<space>-<space>

Sure? My 0042 does it like this:
M$<space>-<space>
M$<space>-<space>Test<space>
M$<space>-<space>Test<space>File.
M$<space>-<space>Test<space>File.txt

[Mesh]

Sure? My 0042 does it like this:
M$<space>-<space>
M$<space>-<space>Test<space>
M$<space>-<space>Test<space>File.
M$<space>-<space>Test<space>File.txt

Ah, well, I was most recently using Build 41.

I'll have to grab 42 and take a look at that.

[ivan]

No point starting another thread since this is directly related to using symbols as word breaks.

Wish: Allow wildcard characters for Search & Replace, including within individual segments.

Justification: Batch Rename templates and RegExp already accept wildcard characters, but support for Search & Replace is currently lacking. Its absence means that patterns that would have been taken care of by wildcard ability have to be hardcoded into a script, which is a painstaking process, especially if you encounter new patterns on a daily basis.

However, this needs to be approached carefully because quite often this wildcard capability would only be required within specific segments. As such, I suggest it would be handled the following way (example of a command) :

Code: Select all

rename s, "#a*b*#/#A*B*#";

In the above, stars would indicate any possible characters between "a" and "b", such letters and/or numbers. Also, this would only apply to a segment that is bounded by # word delimiters. Also, this would not impact the list of word breakers because using asterisks within another set of word breakers would neutralise their normal effect.

I hope I would not be the only one to appreciate the positive effect having wildcards will have, so thank you in advance.

[admin]

No point starting another thread since this is directly related to using symbols as word breaks.

Wish: Allow wildcard characters for Search & Replace, including within individual segments.

Justification: Batch Rename templates and RegExp already accept wildcard characters, but support for Search & Replace is currently lacking. Its absence means that patterns that would have been taken care of by wildcard ability have to be hardcoded into a script, which is a painstaking process, especially if you encounter new patterns on a daily basis.

However, this needs to be approached carefully because quite often this wildcard capability would only be required within specific segments. As such, I suggest it would be handled the following way (example of a command) :

Code: Select all

rename s, "#a*b*#/#A*B*#";

In the above, stars would indicate any possible characters between "a" and "b", such letters and/or numbers. Also, this would only apply to a segment that is bounded by # word delimiters. Also, this would not impact the list of word breakers because using asterisks within another set of word breakers would neutralise their normal effect.

I hope I would not be the only one to appreciate the positive effect having wildcards will have, so thank you in advance.

Please visit this page http://www.xyplorer.com/xyfc/viewtopic. ... 868#p22868 and imagine your wish at about 6 yards below the bottom edge of your monitor. Never mind, but it's time for some of the biggies now.

[ivan]

Please visit this page http://www.xyplorer.com/xyfc/viewtopic. ... 868#p22868 and imagine your wish at about 6 yards below the bottom edge of your monitor. Never mind, but it's time for some of the biggies now.

Well, actually now that you've implemented this:

Code: Select all

v7.70.0003 - 2008-10-20 10:09
  +++ File Find | Contents: Now pattern matching is supported! This
      means you may enter wildcards * and ? in your content definition.
      Rules:
      - Since larger files are read chunkwise (performance!) there are
        certain limits to the scope of your pattern:
        A pattern "a*b" is guaranteed to be found if "a" and "b" are
        within a range of 1,024 bytes! It also *might* be found if "a"
        and "b" are within a range of 1,001 to 32,768 bytes! It will
        certainly not be found if "a" and "b" are only within an even
        larger range.
      - Just like with non-wildcard searches it is assumed that you look
        for a match anywhere within the file, so asterisks (*) are
        silently added to your pattern at both ends in case they are
        missing. This is just to spare you typing too many asterisks. So
        you may simply enter "D?g" to look for "D?g" anywhere in the file
        (match file contents with "*D?g*").

those 6 yards don't seem such a long distance. It's only natural to implement features program-wide rather than part-of-a-program-wide...

[j_c_hallgren]

imagine your wish at about 6 yards below the bottom edge of your monitor

those 6 years don't seem such a long time. It's only natural to implement features program-wide rather than part-of-a-program-wide...

Notice the difference? Yards vs years? There is no relationship here...and are you complaining that a new feature was added, even if somewhat limited in function? If that's the case, then you still don't understand how XY is being developed!

[ivan]

Notice the difference? Yards vs years? There is no relationship here...and are you complaining that a new feature was added, even if somewhat limited in function? If that's the case, then you still don't understand how XY is being developed!

About "yards vs years": my bad, spelling mistake.

About the new feature: I am not complaining about the addition of this new feature, because having more features follows the motto of XYplorer being so individually customizable. However, I am less satisfied that functionality of this feature is not currently incorporated throughout the WHOLE program. Personally, I don't use search at all so this is not useful to me, but I acknowledge that many may find it great. On the other hand, pattern matching in scripting, which is essentially what search is - finding something matching a set criteria, for which wildcards would be greatly beneficial (especially with being able to set the case sensitivity), is feeling badly left out in terms of benefits such functionality would bring. I think it's only fair that if people who use search get wildcards then those of us using scripting a great deal more should get them as well.

[j_c_hallgren]

However, I am less satisfied that functionality of this feature is not currently incorporated throughout the WHOLE program.

Let me put it this way using an old cliche: "Rome wasn't built in a day" --- so as you may have seen, some features are added incrementally instead of waiting for complete set which some app's do. I prefer the piecemeal approach as it's much easier to test and also provides feedback that may mean changes to remaining portions without the need for recoding.

[ivan]

Let me put it this way using an old cliche: "Rome wasn't built in a day" --- so as you may have seen, some features are added incrementally instead of waiting for complete set which some app's do. I prefer the piecemeal approach as it's much easier to test and also provides feedback that may mean changes to remaining portions without the need for recoding.

Yes sir, I have heard that cliché before As much as I can see some sense in the piecemeal approach, the wider the feature is implemented the more people are likely to use and subsequently provide feedback on it. Also, doing quite a bit there but not here is like dangling a bone in front of a dog and smiling as it tries to jump but can't quite get there. May I also say that wildcards are already partially supported in scripting's rename command, just not the "Search & Replace" so adding such functionality is like an apple falling next to the roots of the tree, to use another cliché

[admin]

Let me put it this way using an old cliche: "Rome wasn't built in a day" --- so as you may have seen, some features are added incrementally instead of waiting for complete set which some app's do. I prefer the piecemeal approach as it's much easier to test and also provides feedback that may mean changes to remaining portions without the need for recoding.

Yes sir, I have heard that cliché before As much as I can see some sense in the piecemeal approach, the wider the feature is implemented the more people are likely to use and subsequently provide feedback on it. Also, doing quite a bit there but not here is like dangling a bone in front of a dog and smiling as it tries to jump but can't quite get there. May I also say that wildcards are already partially supported in scripting's rename command, just not the "Search & Replace" so adding such functionality is like an apple falling next to the roots of the tree, to use another cliché

Search & Replace with wildcards? That's not at all the same as determining whether a string matches a wildcard pattern.

[ivan]

Search & Replace with wildcards? That's not at all the same as determining whether a string matches a wildcard pattern.

Either I fail to see something or it's too early in the morning for me. From what I understand, using search & replace uses patterns to identify which files have those patterns present and then it replaces them with predetermined strings/characters. Theoretically, the same mechanism is employed when searching within contents of a file. The only exception is that you don't replace, but still both have the same foundation of looking for a pattern.

[admin]

Search & Replace with wildcards? That's not at all the same as determining whether a string matches a wildcard pattern.

Either I fail to see something or it's too early in the morning for me. From what I understand, using search & replace uses patterns to identify which files have those patterns present and then it replaces them with predetermined strings/characters. Theoretically, the same mechanism is employed when searching within contents of a file. The only exception is that you don't replace, but still both have the same foundation of looking for a pattern.

Give an example, please.

[ivan]

Give an example, please.

OK, here is one:
1. You're searching for ".a?b?." in the content of a file and you find it.
2. Using similar possible scripting command to rename (capitalise the chars in the pattern) :

Code: Select all

rename s, ".a?b?./.A?B?."

As you can see, the initial part of finding matches to the wildcards-included pattern is the same. What you do after, however, is different.