Summary: | EDITING: Cannot search with paragraph breaks or replace with line breaks; inconsistencies in search expressions | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | y3kcjd5 <JLerran> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | crxssi, djreimer, jmadero.dev, kelemeng, libcub, libreoffice, vsfoote, xiscofauli, zen |
Priority: | medium | ||
Version: | 4.0 all versions | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://issues.apache.org/ooo/show_bug.cgi?id=46165 https://bugs.documentfoundation.org/show_bug.cgi?id=43107 https://bugs.documentfoundation.org/show_bug.cgi?id=135538 https://bugs.documentfoundation.org/show_bug.cgi?id=38551 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 102847 |
Description
y3kcjd5
2012-12-25 10:12:53 UTC
This is an enhancement request as nothing is broken. I think this particular bug report is a bit overbearing (multiple suggestion in one go) but since they are all related I'll just mark as NEW and let a developer decide where to go from there. Marking as: New (Confirmed) Enhancement High - quite a few functional suggestions Is this the same as Bug 38261 - Better Find&Replace with regular expressions? tl;dr "regex" that can't handle line breaks and hard returns nicely is not worth the candle *** I'd just like to add my voice to y3kcjd5's (and many others: see linked discussion at 46165) for this "enhancement" to be prioritized. I've scarequoted "enhancement" because not being able to perform the following very common real world use case makes LibreOffice Writer feel DEEPLY BROKEN. Text in which each line break has been converted into a hard return is a common phenomenon: e.g. when copying text from an EMAIL and pasting it into a DOCUMENT. When would anyone ever do that? One simple pragmatic way to fix this using find and replace functionality commonly available in e.g. Microsoft Word, is as follows: Find and replace all occurrences of ¶¶ with e.g. §§§ [mark the pars we do want] Find and replace all occurrences of ¶ with a space [zap the pars we don't] Find and replace all occurrences of §§§ with ¶ [recreate pars we marked in first step] Done. Of course, anyone capable of initiating the sequence above is also almost certainly competent to find a workaround elsewhere. But it feels very broken not just to be able to do it within the application, perhaps because somewhere along the line someone deliberately hobbled \p perhaps because of this 65535 character paragraph limit (huh?). I'm not sure I fully follow y3kcjd5's proposal, but if Writer can be tweaked to make the sequence I outline above easily possible, it would meet most of my regex needs. (In reply to comment #3) I agree! I'd like to add my voice to the request for this development to move to solution. I also support comment #3 and appreciate DouglasCarnall's pithy "tl;dr" that captures the situation nicely. (I can't see what is relevant "inked discussion at 46165", however - is that bug number a typo?) Another "real world" scenario is the possibility of finding and removing duplicate paragraphs. This is a common workflow: sort paragraphs > search on continguous identical paragraphs > remove duplicates. At the moment, so far as I know, this is not possible in Writer, either with the "native" CTRL-H + regex search/replace (which cannot match across $ paragraph boundaries), or with the AltSearch extension (which cannot use back-references in searches with * -- although it can make matches across paragraph breaks). There is some discussion of this at AskLibreOffice: http://ask.libreoffice.org/en/question/27682/regular-expression-references-not-working/ It would be wonderful to see this "fixed"! I also was seeking out a solution to this "bug" as I am increasingly annoyed that I cannot search for $$ and replace with $. Or perhaps $^$ and replace with $. Or \n\n and replace with \n. It is silly that I have to copy text from LO Writer into Gedit so I can do something so basic and then copy it back. Go ahead and try it- it seems it is impossible to remove double newlines in LO/OO! The other thing that makes absolutely no sense to me is even described in the LO/OO help file: """" \n in the Search for text box stands for a line break that was inserted with the Shift+Enter key combination. \n in the Replace with text box stands for a paragraph break that can be entered with the Enter or Return key. """" Really? LO/OO treats \n as two totally different things depending on if it is in the search box or the replace box? That is about as user-friendly as a cracked glass of nitroglycerin! Wouldn't it have made more sense to keep \n as a paragraph break and invent something new or reuse something not used for a line break... maybe use \r or something? I think the current behavior with at least the above example is horribly broken at worst and very poorly designed at best. Seems to me to be a toss-up between a "bug" and an "enhancement". ** 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 (4.4.2 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02 It's still an issue in 5.0. As far as I can tell, this remains unaddressed. I just hit the use case of pasting an email, searching for a solution I found several suggestions with none of them working, so after wasting nearly half an hour trying to `sudo make sandwich s/$/\n/g` I was left to replace paragraph with line breaks manually. \n representing a line break in search and a paragraph break when replacing is obviously & utterly silly. Oh and the workaround mentioned in several posts to just copy a line break and paste it into the replace field did not work on this linux rig. I haven't taken a look closer at the following code, and just a guess. but it gives me an impression that this code has something to do with the behavior described in this bug report. https://opengrok.libreoffice.org/xref/core/sw/source/core/crsr/findtxt.cxx?a=true&r=28bff4bd&h=377#377 oops, typos has => has Example Use Case Just a note to show some of the problems and contortions this causes. In other words it's a use case for an author of a book. In my case, using Writer 6.4.2.2. I wanted to adjust certain paragraphs to have zero indent (i.e. apply my new ChapterBdy1st paragraph style), as per normal book typesetting conventions. So this applies as follows within my book to: A. 1st para of chapter B. 1st para after an empty line ‘scene break’ C. 1st para after an otherwise-empty solo ‘-’ line indicating a change of scene Because some ereaders delete blank lines, I use non-breaking spaces to ensure my 'scene breaks' don't get removed. The following recipe is what I needed to achieve the desired results (took about an hour for a 450pp book): You need to make sure the document is clean: no blank lines at the ends of chapters (otherwise the following chapter header will be found and accidentally converted to ChapterBdy1st). Also check there are no other special cases (like blank lines before quotation indents or poems or lyrics). So a manual scan first is worthwhile. B. For the non-breaking space 'empty' lines: 1. replace all ^<nbsp>$ with an empty line 2. select whole document from starting chapter to end, but omitting early empty paragraphs 3. Find All in Selection of ^$ 4. change paragraph style to ChapterBdy1st 5. select whole document from starting chapter to end, but omitting early empty paragraphs 6. change all ^$ to <nbsp>\n C. Then do a similar replace of solo ‘-’ lines by empty lines, do the above substitutions, except the final one would change all ^$ to -\n, then find all ^-$ lines and apply Centered style and even Chapter Body style: 1. Replace all ^-$ with an empty line 2. select whole document from starting chapter to end, but omitting early empty paragraphs 3. Find All in Selection of ^$ 4. change paragraph style to ChapterBdy1st 5. select whole document from starting chapter to end, but omitting early empty paragraphs 6. change all ^$ to -\n 7. Find All ^-$ 8. Apply Centered style 9. Apply Chapter Body style A. Unfortunately I can’t think of a way to change the 1st para of each chapter via a single F&R. So the final step was to manually find each Chapter Title one by one with F&R, and then select the following paragraph and change it to ChapterBdy1st. That second step 6 (change all ^$ to -\n) should have read: 6. Replace All in Selection ^$ to -\n That second step 6 (change all ^$ to -\n) should have read: 6. Replace All in Selection ^$ to -\n *** This bug has been marked as a duplicate of bug 38261 *** |