(Replying with editing of the order) (In reply to Justin L from comment #35) > The fact that Microsoft has the same 'problem' guarantees that this is > extremely tricky as a computer problem.
Or it reflects that this is a case where one person's bug is another person's feature. There will surely be cases where it is relevant to FIND deleted text, to see what has been deleted. But if you can search within deleted text, then how about Find & Replace? There is surely logic in having the same search mechanism in that case - but in practice, it becomes unlogic to the user. As I asked back in comment 29: Can anybody come up with a case where searching within deleted text and replacing with new text would be the intended behaviour? > The human solution is obvious - turn off View - Show Tracked Changes first. Indeed, this is a good workaround. But it is only obvious if you are aware that you need a workaround. As for myself, I often work with text where changes are visible, and it became a problem for me. (Given the contents of this thread, I do not seem to be alone.) > (In reply to Gerry from comment #19) > > IMHO there are two possible ways to fix this bug: > > (1) Writer should not find search strings in deleted text at all > > (2) Writer finds/replaces search strings but replacement is marked as > > deleted. > There is a third case, and that is when the search string is mixed - part > deleted and part not. > > I think we definitely have to find 'deleted' text. However, if ANY part of > the found string is a deletion, then the replacement probably needs to be > skipped. Indeed, it can be tricky. Here is a suggestion that I think could work as a general solution: Find: Should search within all visible text. When track-changes are shown, the visible text includes deleted text. I.e., searching will include more text when track-changes are shown than when track-changes are not shown. Find & Replace: Should only search within text, that is not deleted. I.e., searching will include the same text (namely the text that is not deleted), whether or not track-changes are currently shown. This does not follow strict logic, but I think it follows user logic. Again, can anybody point to a case where this excludes an intended behaviour? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1126858 Title: [upstream] Search and replace, with tracked changes on, changing only format of text, causes Writer to hang To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1126858/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
