I'd like to see better Find&Replace in all LO programs. It's rather general description, so I'll add that this should include the current functionality of Alternative Find & Replace extension, which doesn't seem to be maintained, and is only available for Writer. Regular expressions should be included. Alternative Find & Replace seems also to solve an issue that Find and Replace doesn't take case of original word in to account, http://openoffice.org/bugzilla/show_bug.cgi?id=17188, with an option Preserve capitalisation.
If it's not a duplicate, I'd like to put this on http://wiki.documentfoundation.org/Vote_for_Enhancement.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
1. Alternative Find & Replace extension was available from http://extensions.services.openoffice.org/en/project/AltSearch but it's not maintained and it doesn't work anymore. The is one of the most important extensions to transfer to LO. 2. The same issue that Find and Replace doesn't take case of original word into account is now on a new address: https://issues.apache.org/ooo/show_bug.cgi?id=17188. For example: if you search case-insensitive for "he" and want to replace with "she", all the instances of "he" which are written as "He" will be replaced by "she" instead of "She". The priority of this issue should be raised. It is an issue that cripples the use of global search/replace. I changed this issue to "major" because of this.
This is an Enhancement Request
Although I track annoying bugs and see that there are other more important but sometimes also not so critical issues, this one is very important to me.
Just to show that Timur is not the only user interested in this enhancement request, I would like to state that this issue is very important for me, too ... Why? An example. Some months ago, I had to typeset a proceedings volume (a 'Sammelband' in German). I would have used LaTeX for this job, but for some external reasons I had to use a word processor; so I used Writer. In the long process of making uniform all chapters (regarding spelling/orthography, interpunctation, abbreviations, citation, formatting etc.), the present Regular Expressions feature of the Find & Replace function was very very helpful for me. Thanks for it! But some special issues were not handled by the Regular Expressions feature as it stands; in some cases I remember I had to open the ODT file with BBEdit in order to search with advanced Regular Expressions for some remaining issues, and then to fix every occurence in Writer manually. If Writer's Regular Expressions feature was better, I could have just used Find & Replace to fix these errors ... This would have saved me some hours of work.
(In reply to comment #4) > This is an Enhancement Request I agree. But having been used to the intuitiveness on commercial products (Word, WordPro), I get a feel like it's a bug. :-)
I edited https://wiki.documentfoundation.org/Feature_Comparison:_LibreOffice_-_Microsoft_Office#Word_processors:_LibreOffice_Writer_vs._Microsoft_Word in order to add Advanced find & replace / Special characters. I marked this as partially supported in Writer and fully supported in Word.
Maybe now that there is Sidebar from Symphony, Find & Replace could be inserted in it? This way it would be unobtrusive while searching/replacing; the good use of sidebar consisting in not covering/hovering over the main text body (an irk in MS Word). Ale the options from Alternative F & R transferred to the new functionality. It would be a huge project, but rewarding. Thank you.
Extension http://extensions.libreoffice.org/extension-center/alternative-dialog-find-replace-for-writer still works. At least it could be bundled with the LO. I agree that Find & Replace could be inserted in the Sidebar, as the 5th tab.
*** Bug 95708 has been marked as a duplicate of this bug. ***
Bump. This bugz me, and always has, that LO, & OO before it, don't have the complex Find & Replace features that are so much better handled in M$ Office. The features of good F&R are pretty much crucial to my effective processing of documents, so I'd like to see this given fairly high priority. F&R is a real 'guts' issue that underpins the bells and whistles stuff. AltSearch 1.4.1 is available but is buggy, not able to complete some of the features that it has and really quite broken on some installations (I tried to install it on a friend's Mac on OO - presume that LO is the same). I'm not a coder, but very willing to help test this. Anyone?
Heiko, can you please look at this one and note whether it make sense to stay open? I noticed some talk on Find&Replace in GSoC, if I'm right. Is Bug 100672 a duplicate? Looks so to me, but I may be biased. Please look at the duplicates here.
(In reply to Timur from comment #13) > Heiko, can you please look at this one and note whether it make sense to > stay open? I noticed some talk on Find&Replace in GSoC, if I'm right. > Is Bug 100672 a duplicate? Looks so to me, but I may be biased. > Please look at the duplicates here. I understand this ticket as RegEx in F&R and 100672 as to add something special on top of it. F&R (as well as the findbar) in the current implementation is the opposite to usability and we should think about a new UI. If you would do the implementation I'd be happy to do the design engineering.
*** Bug 119728 has been marked as a duplicate of this bug. ***
*** Bug 119924 has been marked as a duplicate of this bug. ***
Changing priority back to 'medium' since the number of duplicates is lower than 5
*** Bug 129187 has been marked as a duplicate of this bug. ***
*** Bug 139585 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #14) > (In reply to Timur from comment #13) > > ... > > I understand this ticket as RegEx in F&R and 100672 as to add something > special on top of it. > > F&R (as well as the findbar) in the current implementation is the opposite > to usability and we should think about a new UI. If you would do the > implementation I'd be happy to do the design engineering. Looking through all the related duplicates, I see that Search&Replace is an issue for almost ten years. There is an ancestor bug report from 2003 in AOO! Since writing regexes is not very easy, don't forget to make something like the "batch" feature (store and re-apply stored regexes, being able to give them reasonable names) is not forgotten!
*** Bug 140996 has been marked as a duplicate of this bug. ***
*** Bug 58744 has been marked as a duplicate of this bug. ***
(In reply to Adalbert Hanßen from comment #20) > Looking through all the related duplicates, I see that Search&Replace is an > issue for almost ten years. There is an ancestor bug report from 2003 in AOO! We are in 2021 and no changes. When I explain LO Writer to my pupils and let them now this "must" have about to search "paragraph breaks", I end my class telling them "Maybe this will be solved in future, just after MSOffice become open source." That's my hope about making that search to work from LO :(
since there isn't any way to replace something with a line break, I'd consider this a bug. I consider it is worth some attention by the project! Maybe a bounty could help? I'd participate in it!
(In reply to Jax from comment #12) > Bump. This bugz me, and always has, that LO, & OO before it, don't have the > complex Find & Replace features that are so much better handled in M$ > Office. The features of good F&R are pretty much crucial to my effective > processing of documents, so I'd like to see this given fairly high priority. > F&R is a real 'guts' issue that underpins the bells and whistles stuff. > > AltSearch 1.4.1 is available but is buggy, not able to complete some of the > features that it has and really quite broken on some installations (I tried > to install it on a friend's Mac on OO - presume that LO is the same). > > I'm not a coder, but very willing to help test this. Anyone? "Now", i.e. since 2017, AltSearch 1.4.2 is available. It has some important features: * it can search for regular expressions. Unfortunately the ? quantifier (at least once, but you may circumvent that one by {1,}) and the * quantifier (any number of times including zero times) don't work, also lookback and lookahead-conditions are not supported (e.g. (?<=-)(\d{2})(?=-) meaning exact 2 digits with a minus sign before and after them which are not caught by the regex) * searching for \p and replacing it by \n lets you exchange paragraph marks by forced line feeds, a function which I use very often and which misses terribly in LO Writer and which alone probably would be easily implementabel, * it can search for all occurrences of a given character prototype. Once they are found and marked (unfortunately this takes a lot of time) you can assign just another character prototype to all found samples (LO Writer can't do that), * it can search for all occurrences of a given paragraph prototype. Once they are found and marked (unfortunately this takes a lot of time) you can assign just another paragraph prototype to all found paragraphs (LO Writer also can do that), * it can search for a whole range of other text properties e.g. italics, underline, hyperlinks, ... (I have not tried them out). For men, replace any paragraph marks (including any number of white spaces before them) by a linefeed is the most used function of AltSearch. Due to the implementation in some type of Basic interpreter, AltSearch is very slow. Unfortunately it is not free from bugs. The worst one I know about is that it might remove the whole highlighted region if it is part of a table. To safeguard me from this bug, I always extract the whole range where AltSearch shall be applied (if it is part of a table) to a new document and do the replacements there. When done, I cut it from the intermediate document and paste it to the table where the stuff belongs. Meanwhile LibreOffice has some regular expression capabilities. Lookahead and lookbehind work. Unfortunately \1 \2, \3... for capture groups don't work in the replacement part (one would e.g. use this to transform date in the form mm/dd/yyyy to dd.mm.yyyy or yyyy-mm-dd). The important missing thing in LO's replace dialog with respect to regular expressions is the ability to store regexes + replacement rules and assign names to them in order to reuse them. AltSearch shows a good model for an user interface for that.
Still outstanding since 2011? That's unfortunate. I just came across this shortfall this morning and was disappointed to find that I need to find an extension to do the functionality that LO should do out of the box. Using AltSearch will help on the Writer side but as it doesn't work in Impress or Calc, this will be a never ending frustration. Can we do something to increase the priority? The suggestion of a bounty was also good.
AltSearch 1.4.2 seems not to work from LO 7.5.
It works, but not very stable. From time to time it issues error messages and you end up in a macro definition screen. Also AltSearch is terribly slow. The AltSearch functionality including its ability to store and to reapply stored search patterns plus the ability to uses PCRE regex expressions with all quantifiers (see comment 25) plus the ability to search for character styles, paragraph styles and son on should be in LO Writer itself. The syntax and the way storing/retrieving search patterns should follow the model from AltSearch 1.4.2. That's designed very well. But it has been realized not so well.
*** Bug 161029 has been marked as a duplicate of this bug. ***
Suggestion on bug 161029 was to make this a topic for documentation. Implementation issues should be handled elsewhere.
(In reply to Heiko Tietze from comment #30) > ... a topic for documentation. - on remaining confusion with "wildcards" : https://community.documentfoundation.org/t/lo-7-6-writer-guide-published/11513/14 - and try to move forward with the help : https://gerrit.libreoffice.org/c/help/+/171538
Pierre F committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/e3caa53e99709b7099611b67cf73e9bdbd8801ea more (simple) regex examples + fix note on paragraph limitation. tdf#38261, tdf#159607
The description at https://help.libreoffice.org/latest/en-US/text/swriter/guide/search_regexp.html tells us: "A search using a regular expression will work only within one paragraph. To search using a regular expression in more than one paragraph, do a separate search in each paragraph." This explains why one can not search for a paragraph mark (besides that LO Writer does not have a representation for it). In AltSearch a paragraph mark is represented by \p and a forced line feed is represented by \n. There one can exchange \p by \n, which is an operation which I do very often when I am documenting code: It enables quick navigation by paragraph using Ctl-arrow-up or Ctl-arrow-down. My most applied search and replace operation can't be done with LO Writer's own search and replace because of the restriction **only within one paragraph**. Of course doing a separate search, as suggested, is just making all those changes manually.
*** Bug 165725 has been marked as a duplicate of this bug. ***
For reference. <<<<<<<<<<< Subjet : Re: Minutes from the UX/design meeting 2025-Mar-26 Date : Thu, 27 Mar 2025 08:02:23 +0100 From : Heiko Tietze <heiko.tietze@documentfoundation.org> Organisation : The Document Foundation To : libreoffice@lists.freedesktop.org On 27.03.25 3:19 AM, Regis Perdreau wrote: > Hi, in find and replace, we ask for ages to be able to replace end of paragraph by end of line. If you implement some regex tools, I think this request is legitimate. There might be a million use cases. However, most user need basic functionality and are overwhelmed by the F&R dialog (and other) right now. It is easy to provide Regex functions via extension and the decision was to rather not expect functional completeness on the F&R dialog (yet improvements are welcome). >>>>>>>>>>> Questions: - where can this "decision" be found / read ? - shouldn't it be mentioned in the documentation ?
(In reply to fpy from comment #35) > - where can this "decision" be found / read ? Bug 165725 (which is a duplicate of this one now)
(In reply to Heiko Tietze from comment #36) > (In reply to fpy from comment #35) > > - where can this "decision" be found / read ? > > Bug 165725 (which is a duplicate of this one now) - I'm a little concerned with the "off-topic" tags since this bug was (at least partly) about improving the documentation. cf #c30 - Now we have a "decision" promoting an extension; what is the consistent approach to let a user know ?
*** Bug 165724 has been marked as a duplicate of this bug. ***
I am vexed by this peculiar bug. It is not a meta bug (we have bug 146076), but still has many requests/ideas/complaints and a long list of dupes and related bugs. And because of this fact, it serves as an excuse to close almost any new bugs regarding F&R with regular expressions - since such bugs typically overlaps enough of what's been discussed here, that someone can mark it a dupe. That is a sad state of affairs, which I believe needs to stop. I therefore suggest that we: 1. Un-duplicate most/all of the bugs currently duplicated to it, and make them block one or more of the meta-bugs (Find-Search, Find&Replace-Regex, Find&Replace-Dialog) 2. Un-relate the see-also bugs currently associated with this bug, consider which of them should block which of the meta-bugs, and which of them relate to each other. 3. Close this bug 4. Open new bugs for more _specific_ requests, which block the F&R regex meta-bug; and in those bugs, we can quote from (just one of) the discussions here. Of course these measures are not intended to validate or invalidate any of the issues/suggestions/push-back in the comments on this bug! It's just about untangling the mess. Some other notes: * I've already performed a small bit of dupe culling and re-titling (e.g. bug 119924). * Adalbert Hanssen: You write that "Unfortunately \1 \2, \3... for capture groups don't work in the replacement part" - they do work, but not in this format; rather, you need to say $N instead of \N, so $1, $2, $3 etc. This is not unique to LibreOffice, it's the same, in say, JetBrains IDEs. If you oppose this, I suggest you open a separate bug. * I've already taken my own advice in item (4.) and filed a few specific bugs of my own against Find&Replace-Regex (bug 146076), you are all welcome to have a look.