When writing a document, sometimes one character is auto-replaced with another, such as when we keyboard-input a straight apostrophe and a curved apostrophe appears in its place. That's good, but the problem occurs when we try to find a string with the auto-replaced character, because the string to be found does not have auto-replacement applied to it. The result is a failure to find. The solution is to permit auto-replacement to apply to the Find field, probably as a default users can disable. Closely related is that Find and Replace should apply auto-replacement to the replacement text, also as a default users can disable. If a newer version of Writer has this, that's good enough. The version I'm reporting on has still been getting updated even after reputedly being at EOL. I guessed my hardware.
Seems like an interesting concept so lets see what the ux-advise team thinks. As auto-replacement does happen in a document, if a user typed the exact same thing in the find & replace dialog as in the document, it wouldnt find a match, but if a user highlighted what they had typed, it would find a match. As an example, typing the following in Writer and search for it would result in no found matches :- "My name is Yousuf" Doing the same in MS Word would find a match as they likely replace non-regular expression searches with a regular expression version of the same to pickup up auto-replacement variants.
I use the auto replacement frequently for --> which creates an arrow. I never would expect it to be available in the search by -->. But with digraphs or strange characters we run into trouble. Is it possible at all to find such a text? If so we could offer a checkbox "look for replacements" or rather show those results in a different color. By the way: I hate the LO find and replace dialog. Not sure if its true for Writer but in Calc I replace A by 1 and B by 2 and so on and have always to dismiss the result dialog. And since "only selection" is hidden and unchecked by default I regularly do the task twice.
Highlighting helps with the Search field but not for the Replace-With field, although we can select from elsewhere and copy into that field and edit it before clicking a button to find or replace, a complicasted method for nongeeks to remember, especially whern the cause is not always obvious (in the small size of the dialog's font it's hard to see that quotation marks are not curved). I use Writer partly to write website content in HTML, so the string "-->" is very useful as is, since it's a comment closer. But the commenter's point is well-taken for some other strings. Quotation marks and apostrophes are usually auto-replaced except in the search-and-replace dialog. Color alone should not be a differentiator, because that prevents accessibility for people with a color-perception problem. Color combined with a noncolor cue would be okay. I replaced "A" by "1" etc. and got either "Search key not found" or "Search key replaced 2 times". The latter is useful. The former is, too, except when it comes after having done the replacement using the Replace button, when it should instead say how many replacements have been done (one), as it does when the Replace All button is used. So the problem is with the Replace button. The Replace button causes the stroing to be selected but not replaced yet. Clicking the button again causes replacement but also gets an offer to start from the beginning of the document and clicking yes to that gets the not-found result. Clicking the Close button is okay but clicking the Replace button makes sense, getting the odd result. So the Replace button's result should be fixed. Calc is similar but not identical. It may be that the Replace button remains selected so that pressing the Enter keyboard key causes the confusing result. This generally seems like a usability-friendliness issue rather than a technical internals one. This may need a separate bug report.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Going through the old tickets with needsUX; sorry for the delay. We talked about this topic in the design meeting and agree with the problem. Solution could be to not only search for the actual term like ' or --> but also for the autocorrected forms ‘’ (open and close) or → respectively. Could be enabled via checkbox but I'd suggest to just always do it.
There should also remain a possibility to search only for the characters that weren't changed by autocorrect. Consider a situation where a document is turnwise edited in several computers, with different LibreOffice settings (e.g. autocorrection of quotes on/off) -- in a final step of editing, it should remain possible to search & replace e.g. only the non-corrected straight quotes. So a checkbox to this effect would be optimal (although it could very well be enabled by default).