Why does Writer freeze after Searching and Replacing line endings with spaces?

[nsivin]

I am using Writer 4.2.4.2 in US English under Linux Mint 17 on a fast PC with 4GB of RAM to reformat a downloaded .odt file of about half a megabyte. I tried to do a simple search and replace to convert the carriage returns at the end of each line into spaces (a total of about 5000 replacements). As soon as the change has taken place (and is visible), an error message appears telling me that Writer can’t do the replacements unless I turn off Undo first—although I can see the changed file. No matter how I reply (Yes, No, or Cancel), the screen freezes entirely and I can’t do anything to save the changes. No forced quit works; I have to turn the computer off manually and recover the file (without the changes). For some curious reason, accessing the help file doesn’t explain how to turn Undo off.

This appears to be a genuine bug. Is there actually some way to turn off Undo?

By the way, I am not trying to reduce a long document to one paragraph, simply converting a file so that the lines in a paragraph wrap. The Project Gutenberg document I downloaded has a CR at the end of every line, and two of them at the end of every paragraph. I first convert all the double CR’s to a #'s (there are only about 500, so no problem), then convert the remaining CR’s to a space, then convert the #'s to one CR, since that’s all I need. I’d be surprised if Writer was not able to handle 5000 replacments. I used to do this routinely on even longer files with Word 2000 under WinXP.

[CyanCG]

The thing about Undo looks like a bug indeed, but why replace all carriage returns with spaces? Is it because you want the document to be only one paragraph? LibreOffice Basic indeed has a hard limit to the number of characters that it can handle in a string: 65534, which is the highest number that can be represented with 16 bits. However, I don’t know if that limit applies to the paragraphs themselves. In any case, the character limit is internal to LibO, as the saved XML has no such limit.

[CyanCG]

Now, if you must have absolutely no paragraph breaks in your text, you might find it hard to obtain this effect in LibO, but in CSS (hence, in a Web browser) you can set an element’s display property to inline! Of course, that doesn’t help much if you must produce a printed document.

[Lupp]

@CyanCG - @karolus - Want to point out again that @nsivin did NOT talk of replacing NewParagraph by Space but replacement targetted on NewLine. As I stated in my comment on Karolus’ answer the ‘Search & Replace’ DOES offer replacing NewLine (\n) by Space without touching the NewParagraph occurrences. This may be a bit unclear because \n in the ‘Replace with …’ control will insert a NewParagraph indeed. If there WAS NO NewParagraph ijn all the text LIMITS WERE ALREADY STRIDDEN in advance.

[Lupp]

‘Tools’ > ‘Options’ > ‘LibreOffice’ > ‘Memory’ > ‘Undo’ spinned down to 0.

[begin EDIT] Sorry! My answer was to rash. I never did that for a long time now and the behaviour of the sofware may have changed. Just tried out my own suggestion and found a minimum of 1 for the ‘Undo’ number. [end EDIT]

[begin EDIT2]

nsivin:

I first convert all the double CR’s to a #'s (there are only about 500, so no problem), then convert the remaining
CR’s to a space, then convert the #'s to one CR,

Just got aware of the changements nsivin’s made by editing his question. Now I have to ask for putting it clear: Are there “new line” AND “new paragraph” breaks or only ONE kind of them? Which one? What is meant by “CR” in the CONTEXT of a Writer document?

If things are as I guess you may want to study the attached example. Limitations need obeying also with intermediary content. ask36237FindReplaceLineParagraph001.odt

[end EDIT2]

[nsivin]

In the search and replace that didn’t work, I searched for $ alone and replaced it with a space. Both $^ and \n give a “search key not found” error.

[Lupp]

1. You can find EMPTY paragraphs by searching for ^$.

2. This won’t really help you because there seems to be no way to get the paragraph break AT THE END of a not empty paragraph as the SEARCH RESULT which might be replaced. Except for $ allone and ^$ you will always just get replaceable sequences in front of the break.

3. Thus the only workaround for your problem I can see is: Go back to your original approach and ply with selected portions of about 20 pages (less than 2^16 characters).