Find & Replace > Replace all - "xxx" becomes "x"

[Oufti]

When searching and replacing a single character (e.g. replacing a by z) and if the letter is repeated in the text (aa aaa …), the repeated letters are reduced to a single letter (aaa becomes z) after clicking the button Replace all. 

I would expect that aaa becomes zzz.

N.B. When using repeatedly the Replace button instead, every single letter is correctly replaced. 

[Affinity Publisher for Mac 2.1.1, macOS Monterey 12.6.7.]

 

P.S. Could this above be related to that ancient bug? 

 

[MikeW]

I don't know what the expected behavior is, but y'all know regex can accomplish this, right?

[walt.farrell]

1 hour ago, Red Sands said:

Would also be nice with a summary: "replaced x occurences". The matches list can get mighty long and getting that info is quite normal in word processors and text editors after replacing text. 

The Find operation, at least has a result count coming in 2.2: 

 

 

[walt.farrell]

3 minutes ago, MikeW said:

I don't know what the expected behavior is, but y'all know regex can accomplish this, right?

That's kind of the reverse of what the OP wants, and what it should be doing as far as I know.

[MikeW]

30 minutes ago, walt.farrell said:

That's kind of the reverse of what the OP wants, and what it should be doing as far as I know.

Ok. Whatever. My understanding was Replace All with a non-regex f/r wasn't working whereas Replace All with the above regex does work.

So, what is my misunderstanding?

[Oufti]

51 minutes ago, MikeW said:

Ok. Whatever. My understanding was Replace All with a non-regex f/r wasn't working whereas Replace All with the above regex does work.

So, what is my misunderstanding?

Thank you for your regex. I tried it but I had the same (unwanted) result as with my f/r normal query: 

Searching for: ([x+]) — I'm not proficient enough in regular expressions to figure out immediately what it's supposed to do?... (After a short research, it looks like it is doing on purpose what I want to avoid.) — and replacing by: x then clicking Replace all resulted also in replacing the suite xxxx by a single x.
This is not what I want!

I want that searching for x and replacing it by x results in xxxx being replaced by xxxx. 

And even if it is certainly possible to use a regex as a workaround, or for more specific tasks, it doesn't seem acceptable to me that double letters are replaced by single ones if it is not asked for. 

Look at this again:

• Type: The bell on the wall tolls.
• Find: l
• Replace by: ℓ
• Do you expect the result to be 1) or 2)?

1) The beℓ on the waℓ toℓs.
2) The beℓℓ on the waℓℓ toℓℓs.

With "Replace all", I get the first but I want the second – as I get with the "Replace" button.

[MikeW]

Did you turn on regex as the find/replace option?

At least here on Windows, the Replace All works as it should, with regex turned on anyway. 

[Oufti]

24 minutes ago, MikeW said:

the Replace All works as it should

I don't know what you mean hereby… 

I thought I was clear about what I want F/R to do: 

(On the left, the text before search and replace. On the right, result of Replace all.)

 

BTW, when I tried your regex ([z+]), it was well with the regex option enabled. (And the result was what I suppose you intended: looking for (a suite of [one or plus z-letter]) and replacing it all by a single z — not at all what I wish).

And above all, what I want to achieve should not require the use of any regex.

It seems to me to be just a bug, to signal and avoid.

Thank you. 

[Oufti]

21 minutes ago, Oufti said:

1 hour ago, MikeW said:

[…] the Replace All works as it should […]

I don't know what you mean hereby… 

21 minutes ago, Oufti said:

1 hour ago, MikeW said:

Did you turn on regex as the find/replace option?

At least here on Windows, the Replace All works as it should, with regex turned on anyway. 

BTW, when I tried your regex ([z+]), it was well with the regex option enabled. (And the result was what I suppose you intended: looking for (a suite of [one or plus z-letter]) and replacing it all by a single z — not at all what I wish).

Here is illustrated what happens when I apply your regex:

 

Is that the expected result or anormal? As I am not sure what your code is supposed to do, I can't tell… 

But it is definitely not what I wanted! 

Thank you anyway. 

[MikeW]

Does the following video demonstrate what you want to accomplish?

If so, perhaps version 1.x applications work properly--assuming you are using v.2 APub. I don't have version 2 version yet. But, if the issue is related to v.1 versus v.2 versions, that is a regression. Like I mentioned, I'm using Windows but don't know if you are on a Mac or Windows PC. I am using the .exe installers, maybe there's a difference. Maybe it amounts to the language localization. Dunno.

If others with varying versions (1 v. 2) and/or installed types (msix v. exe) could give a try it may help to figure it out.

 

 

[Dan C]

Hi @Oufti,

Thanks for your report!

I can confirm that I've been able to replicate this behaviour here and have logged it with our developers as a bug.

I hope this helps

[Oufti]

12 hours ago, MikeW said:

Does the following video demonstrate what you want to accomplish?

Yes, it is. Thank you for all your tests.

Therefore the idea of using a regex instead of a normal search turns out to be a dead end... Both searches are faulty here. 

12 hours ago, MikeW said:

I'm using Windows but don't know if you are on a Mac or Windows PC.

I am on a Mac M1 MBP 14" with Monterey 12.6.7 (in French fr-BE) and Publisher v.2.1.1 (as indicated in my signature). Thus this confirms that my Mac and APub v.2 don't behave in the same way as your PC with APub v.1.

Alack…

++++++++++++++

To conclude, thanks to further experiment by @MikeW, we discovered in my configuration two bugs with Replace all, both of which causing a sequence of several identical letters to be replaced by a single character (aaa becomes A). 😞

1. Normal search — Find a and Replace all with A. 
2. Regex search — Find ([a+]) and Replace all with A.

[Oufti]

5 hours ago, Dan C said:

I hope this helps

Well… It will.
In the future (probably)… 🤭

At present, it's already better to know than to ignore that searching for l and replacing by itself would transform my first sentence into this: “Wel… It wil […]”

But it is altogether quite annoying not to be able to f/r a single character (or even a string of) when it is repeated in the text.

I hope it wil be fixed son…  

Many thanks anyway!

+++++++++

[Being serious]

Further investigation shows that the same weird behaviour occurs for any repeating pattern.

E.g. Find: "pqr" and Replace all: "PQR" will change "pqrpqrpqr" into a poor "PQR". 

 

[Dan C]

No problem at all!

17 hours ago, Oufti said:

Further investigation shows that the same weird behaviour occurs for any repeating pattern.

E.g. Find: "pqr" and Replace all: "PQR" will change "pqrpqrpqr" into a poor "PQR". 

I've been sure to include both updates in the development log to ensure this is marked as not only affecting repeating singular characters - I suspect one resolution from our developers should resolve all cases

[Oufti]

12 hours ago, Dan C said:

I've been sure to include both updates in the development log to ensure this is marked as not only affecting repeating singular characters

Thank you again.  

 

12 hours ago, Dan C said:

I suspect one resolution from our developers should resolve all cases

I believe the same thing, and I hope they'll soon work out how to solve this problem.

[Affinity Info Bot]

The issue "Find and Replace - Replace All with singular characters reduces multiple repeats to singular, different results with multiple Replace clicks" (REF: AFB-8088) has been fixed by the developers in internal build "2.2.0.1951".
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.

[Oufti]

On 7/21/2023 at 12:12 PM, Dan C said:

I suspect one resolution from our developers should resolve all cases

Thank you very much. I have tested in v.2 (ß1954) and all is correct. 👍