In the Find & Replace Dialog a Replace All with an empty replace text does not function if the search criterium contains a Format. To reproduce: 1. Open a new Writer document 2. Enter some text and sprinkle the word "test" a couple of times in it. 3. Give (some of) the words "test" a font color, e.g. Red. 4. Open the Replace & Find dialog. 5. In the find text field enter "test" (without the quotes). Leave the replacement text empty. 6. Click Other Options > Format > Font Effects > Font color and select Red 7. Click Replace All. The dialog answers with "Search key replaced xx times." but in reality the texts are not replaced. Replace All does work if no format is selected, and/or if the replacement text is not empty. It also fails if other formats are selected, e.g. Font. An easy workaround is to click "find All" and then delete the selected text, but the Replace All should also work.
I can confirm with Version: 5.2.0.0.alpha0+, 4.5 ; win7
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
*** Bug 118174 has been marked as a duplicate of this bug. ***
Dear Piet van Oostrum, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
If the Replace field and formatting is empty, Replace All does nothing (other than highlight the occurrences). If the Replace field has no text but has formatting, it swaps out the formatting (but does not delete the text). I would expect an empty Replace field to delete all found occurrences (like it does for plain text find and replace). Tested using: Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Reproduced in: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: f446a203fa2897bab8ae7686c948a8bf060675c6 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-24_15:16:38 Calc: threaded and: Version: 7.2.0.0.beta1 / LibreOffice Community Build ID: c6974f7afec4cd5195617ae48c6ef9aacfe85ddd CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 112840 has been marked as a duplicate of this bug. ***
According to duplicate Bug 112840, this is inherited from OOo.
Dear Pieter van Oostrum, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Tested again with LibreOffice 26.2.1.2 (build 8399f6259d8c87f40e7255cdb3c9b958f5e08948) AARCH64) The bug is still the same.
Having empty replace field has special semantics, when formatting is used. 1. You may have both Find box and Replace box empty; have Find format X, and Replace format Y: this finds all occurrences of formatting X, and replaces with formatting Y, *keeping text*. 2. You may have some text in Find box, and empty Replace box; have Find format X, and Replace format Y: this finds all occurrences of formatting X *on Find text*, and replaces with formatting Y, *keeping text*. Note that empty Replace consistently means *keep text* here! Basically, in this case, it also "replaces", as it claims - just the empty replacement formatting means "do not apply any changes". The "replace text with nothing" could be only a reasonable expectation in case when "replace" set is also empty...
(In reply to Mike Kaganski from comment #11) > The "replace text with nothing" could be only a reasonable expectation in > case when "replace" set is also empty... And even then: what would be a reasonable expectation, when Find text is empty, too (only Find formatting is set)?
I think of searching a format and replacing it leaving the replace box empty should replace the text. However, if you add a format change and an empty box, the text should remain. Can this be a viable option?
(In reply to Andreas Heinisch from comment #13) > I think of searching a format and replacing it leaving the replace box empty > should replace the text. However, if you add a format change and an empty > box, the text should remain. Can this be a viable option? The last item, yes. An empty text with a format does not make sense, so if there is a replace format and the replace text is empty, leaving the text unchanged is a logical option. However, this leaves us with one ambiguous case: If the search text has a format selected, and the rplace text is empty end the replace format is empty, y=this could mean two things: 1. remove the text (obviously with the format). 2. remove the format, but leave the text. The use should then have the possibility to indicate which one is desired. It should be clearly indicated, son that the user is aware that both are possible. I see two possibilities: 1. an option to indicate "leave the text unchanged". This removes any ambiguity. 2. an option "remove format". There is also "Attributes". Does the same apply to these?
Current discussion: https://gerrit.libreoffice.org/c/core/+/201713
(In reply to Pieter van Oostrum from comment #14) > However, this leaves us with one ambiguous case: If the search text has a > format selected, and the rplace text is empty end the replace format is > empty, y=this could mean two things: > 1. remove the text (obviously with the format). > 2. remove the format, but leave the text. In no case the empty replace format means "remove format". Format is only positive, never negative: what is explicitly defined in format gets applied (replacing current value of that property), but missing properties are not unset. So - no ambiguity here.
(In reply to Mike Kaganski from comment #16) > (In reply to Pieter van Oostrum from comment #14) > > However, this leaves us with one ambiguous case: If the search text has a > > format selected, and the rplace text is empty end the replace format is > > empty, y=this could mean two things: > > 1. remove the text (obviously with the format). > > 2. remove the format, but leave the text. > > In no case the empty replace format means "remove format". Format is only > positive, never negative: what is explicitly defined in format gets applied > (replacing current value of that property), but missing properties are not > unset. So - no ambiguity here. So then how do you accomplish this: from all texts matching a regular explression with color red, remove the red color? My guess would be to have the format empty in the replacement. Unless there would be an option "remove format".
(In reply to Pieter van Oostrum from comment #17) > So then how do you accomplish this: from all texts matching a regular > explression with color red, remove the red color? My guess would be to have > the format empty in the replacement. Unless there would be an option > "remove format". 1. You are changing the topic of this specific issue. Anything except "Replace All with format in search and empty replace text does not replace" is off-topic here, and needs a separate report / discussion. 2. Answering it, though. First, what does "remove color" mean? Do you imagine a "text without a color"? Or is your idea "apply automatic color"? Or are you talking about resetting the color to inherited value - translated as "remove direct formatting"? Depending on your answer: "remove color" in strong sense is meaningless; applying automatic color means you explicitly choose automatic color, so again have a setting in the formatting set; and there was never, and still is not, a "remove direct formatting" mode of the discussed dialog (so implementing that would be a new feature - again, for a separate report). And its implementation would still require you to explicitly define which properties you intend to reset (so you would have to choose a property, likely some special "reset" value, which would then be in the formatting set, and will be "applied" in a special way by the operation).
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/73b7ac240ecb8f875e869744d60651280a7945fa tdf#99672 - Allow replace with empty string when a search format is set It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #19) > Andreas Heinisch committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 73b7ac240ecb8f875e869744d60651280a7945fa > > tdf#99672 - Allow replace with empty string when a search format is set > > It will be available in 26.8.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Please see tdf#171825. Similar issue, but different scenario. In my test case, I set format and leave "Find" field empty, but fill the "Replace" field (that's the case our users reported back). Replace works, but not Replace All. And this commit does not fix our case.