Seperate Find and Replace fields

[Mesh]

I would like to submit the request that all find/replace sections in XY use two seperate fields for the match and replacement fields.

Having everything in one field is unwieldy, reduces readability, and causes complications in parsing.


For example, when using RegEx renaming, because the seperator between the match and replacement sections can have an optional space on either side of it, the field ends up ignoring leading or trailing whitespace in general - which makes it impossible to use it as part of the RegEx.

So, if you have a file named "Test File Document.txt", and you tried to match " File ", it would only match "File". Similarly, if you wanted to replace "File" with " New ", it would only add "New".

This would not occur if there were seperate fields for the match and replacment text, as there would be no need for XY to figure out where each section starts and ends. In addition, there are additional complications in parsing, because it is possible for the seperator character to be part of the matching or replacement text.


The easiest and cleanest way to address all of these issues are to have two seperate fields, which is what I humbly submit as a request.

[TheQwerty]

While I agree having separate fields might be better, you are wrong about it being impossible to use leading/trailing whitespace.

All you have to do is write better patterns:
"File[ ]" or "File\s" will match "File "
"File(.?)>New $1" will add "New "

[Mesh]

While I agree having separate fields might be better, you are wrong about it being impossible to use leading/trailing whitespace.

All you have to do is write better patterns:
"File[ ]" or "File\s" will match "File "
"File(.?)>New $1" will add "New "

Well, first of all, that's not writing better patterns - it's writing patterns adapted to the current limitations. You shouldn't *need* to do that. And you wouldn't with seperate fields.

But aside from that, your example doesn't quite work in all cases. If we had "TestFileDocument.txt" and I wanted to replace "File" with " File ", there would be no capture group to work with in order to jury rig those spaces (not to mention that it's horrendous to *need* a capture group just to add spaces).

[j_c_hallgren]

While I agree having separate fields might be better, you are wrong about it being impossible to use leading/trailing whitespace.

All you have to do is write better patterns:

Well, first of all, that's not writing better patterns - it's writing patterns adapted to the current limitations. You shouldn't *need* to do that. And you wouldn't with seperate fields.

Based on TheQwerty's reply, at least there is a partial workaround for now until there is a better solution...yes, it's not ideal, but we all sometimes have to 'jury rig' things once in a while..

And that makes at least two people who think there is some room for improvement in this area...I'n neutral for now, as I rarely use this.

[Mesh]

Based on TheQwerty's reply, at least there is a partial workaround for now until there is a better solution...yes, it's not ideal, but we all sometimes have to 'jury rig' things once in a while..

And that makes at least two people who think there is some room for improvement in this area...I'n neutral for now, as I rarely use this.

His suggestion only works in certain limited scenarios. But, in any case, this is simply a feature request.

RegEx is extremely useful, and worth learning for people who do extensive text work. I was thrilled to see XY support it, and I look forward to any way that it's functionality can be enhanced.

[jacky]

Well, the way I look at this, it's actually a bug here that XY trims the pattern. Indeed this in regexp won't work as expected:

Code: Select all

 foo >bar

because XY will trim and use "foo" without any space.

But, with a Search/Replace rename operation there's no problem, because XY doesn't trim so

Code: Select all

 foo /bar

will replace " foo " with spaces included.

So shouldn't just this be fixed, and have XY not trim patterns on regexp ?

[Mesh]

So shouldn't just this be fixed, and have XY not trim patterns on regexp ?

The trimming of spaces can be treated as a bug fix. But that doesn't address the readability issue, nor does it address the problem of the seperation character being a legitimate character in RegEx statements.

For the short term, I would suggest that the leading/trailing spaces issue be corrected - because that can be done during a commercial break.

But for the long term, I think it would simply be an improvement for XY to use double fields. There's a reason why most programs do it that way, in my opinion.

[TheQwerty]

If we had "TestFileDocument.txt" and I wanted to replace "File" with " File ", there would be no capture group to work with in order to jury rig those spaces...

Code: Select all

(.?)File(.?)>$1 File $2

[admin]

If we had "TestFileDocument.txt" and I wanted to replace "File" with " File ", there would be no capture group to work with in order to jury rig those spaces...

Code: Select all

(.?)File(.?)>$1 File $2

Rename Special / Search & Replace: File/ File
Where's the problem?

And general reply to Mesh's wish: rather not. For me it's one of the strong points of XY that those tasks can be defined in simple 1-piece text lines. For example, List Management's "Editor Mode" makes good use of this. Also Scripting, in a way, is also a method to squeeze UDC forms into one-liners. I just like the compactness and integrity of them, their copy-and-pasteability. (DNA is a one-liner as well... )

[Mesh]

Rename Special / Search & Replace: File/ File
Where's the problem?

Well, first of all, it's a crutch. The RegEx replace *should* be able to do it. Moving to a different method is only necessary because the Regex rename doesn't work as it's supposed to.

But the second reason is that this was only a simple example; there are many more complicated patterns that would require RegEx instead of Search & Replace, but would need to be able to work with leading/trailing spaces.

And general reply to Mesh's wish: rather not. For me it's one of the strong points of XY that those tasks can be defined in simple 1-piece text lines. For example, List Management's "Editor Mode" makes good use of this. Also Scripting, in a way, is also a method to squeeze UDC forms into one-liners. I just like the compactness and integrity of them, their copy-and-pasteability. (DNA is a one-liner as well... )

In that case, might I suggest the following:


1. Eliminate the optional spaces around the seperation character so that there is no pre-parse processing (try saying that six times fast).

2. Add the ability to change the seperation character. You can do this either via an additional field in the dialog box, or through XY's primary INI file. This way, if I need to use a ">" in my RegEx, I can choose a seperation character that doesn't appear in my statement. I would also recommend that you not limit it to a single character - that way, a person could choose ">>>" as their seperation text, for example. Heck, if you did it that way, a user could configure it to be " > ", which would use spaces around the seperation character, but would not strip out any additional spaces, even if it were right next to it (e.g. <space><space>CHARACTER<space> would still recognize the first space as being a trailing space that was part of the match statement).


Is that an acceptable compromise?

[admin]

1. Eliminate the optional spaces around the seperation character so that there is no pre-parse processing (try saying that six times fast).

2. Add the ability to change the seperation character. You can do this either via an additional field in the dialog box, or through XY's primary INI file. This way, if I need to use a ">" in my RegEx, I can choose a seperation character that doesn't appear in my statement. I would also recommend that you not limit it to a single character - that way, a person could choose ">>>" as their seperation text, for example. Heck, if you did it that way, a user could configure it to be " > ", which would use spaces around the seperation character, but would not strip out any additional spaces, even if it were right next to it (e.g. <space><space>CHARACTER<space> would still recognize the first space as being a trailing space that was part of the match statement).

Is that an acceptable compromise?

Yep, sounds good. Any objections anybody?

[PeterH]

That's a fine problem...

I always love "variable" spaces.
But even more I love, if a definition is unambiguous.
That is: I don't like this kind of separator.
(and so understand Mesh's wish)

But if this separator should be kept I'd vote for "no optional spaces" - to make it unambiguous...
...but maybe a problem for people now using them?

[Mesh]

But if this separator should be kept I'd vote for "no optional spaces" - to make it unambiguous...
...but maybe a problem for people now using them?

The solution I proposed would allow people to set the seperation string to ">" or " > ", which would match older statements. The only time there would be a complication is if a person uses both - in which case, they would need to choose one. A small inconvenience for what is being gained in return.

[admin]

But if this separator should be kept I'd vote for "no optional spaces" - to make it unambiguous...
...but maybe a problem for people now using them?

The solution I proposed would allow people to set the seperation string to ">" or " > ", which would match older statements. The only time there would be a complication is if a person uses both - in which case, they would need to choose one. A small inconvenience for what is being gained in return.

I agree. I will default the separator to " > ". If your old statements use ">" without blanks around you will get an error message "Missing separator...". If you used " > " before then all works as before. The only surprise would be for statements using more than one blank around " > "... in that case either the RegExpPattern is not found (no replacement takes place), or superfluous blanks are inserted.

The last case could be a reason to write extra backward compatibility code... hmmm..

[Mesh]

Works great! Thanks, Don!