Description: Recent fix 117643 only addressed half the problem of apostrophes not working when performing a search. Only the trailing single quote was coded for, not both apostrophes. example: John said, "you know he meant 'go away' when he said 'hi'." Steps to Reproduce: 1. Open Writer 2. Type 'hi' 3. Attempt to search for it Actual Results: Not found Expected Results: Should be found Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha1+ (x64) Build ID: 42a691933429dbb315de2bd7ba2724993c60411f CPU threads: 8; OS: Windows 10.0 Build 20257; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 167332 [details] quote example O'clock is found, 'hi' is not.
Not working in Version: 7.1.0.0.alpha1+ (x64) Build ID: ccd0e5f445d4a7d0e7aca6c23c02c61bf14510b2 CPU threads: 8; OS: Windows 10.0 Build 20257; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Will wait for another daily build.
Still a problem under 7.2.0.0 alpha 0 Version: 7.2.0.0.alpha0+ (x64) Build ID: f313e27fb7f2d42247407e26e16f264e30f87ca5 CPU threads: 8; OS: Windows 10.0 Build 20262; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Still a problem with the trailing quote in Version: 7.2.0.0.alpha0+ (x64) Build ID: 561e5559bb68242c7f785f0ca3bee3eb12b58963 CPU threads: 8; OS: Windows 10.0 Build 20270; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I can't reproduce it in Version: 7.2.0.0.alpha0+ Build ID: 84af20ef3ea72190784e9e7be820684c2558ba8c CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
(In reply to Xisco Faulí from comment #6) > Thank you for reporting the bug. To be certain the reported issue is not > related to corruption in the user profile, could you please reset your > Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and > re-test? > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the issue is still present I will, but have you tried reproducing the bug in the environment that the bug was identified? You tested in Linux, I'm on Windows. They're not 1:1 in terms of bugs.
(In reply to Xisco Faulí from comment #6) > Thank you for reporting the bug. To be certain the reported issue is not > related to corruption in the user profile, could you please reset your > Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and > re-test? > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the issue is still present In WINDOWS, this bug still happens on a brand new profile. Search finds: can't Does not find: 'hi' as if searching for a partial quote embedded in a sentence.
Like most word processors, LibreOffice by default turns on smart quotes, so it CHANGES a u+0027 straight single quote into an open or close quote. If you copy the 'hi' from the text and paste it into the search, it will find it. It is actually rather DANGEROUS to do what bug 117643 did and have a search for the straight quote match a smart quote. What if I wanted to find all the instances where a straight quote was used instead of a smart quote? I wouldn't be able to do it. So search really ought to find ONLY exactly what the user entered. I would resolve this as WONTFIX, and I would flag commit d40f2d02df26e216f367b5da3f9546b73f250469 as a regression (although there is "regular expression" that "fixes" that - which also isn't intuitive to the average user).
Unfortunate. MS Word will search either quote format seamlessly without a pitchfork rebellion from its user base that such happens, and I'd expect any other word processor to accomplish the same.
Created attachment 171232 [details] Example file with single and double apostrophes and their typographic versions Can't reproduce this in 7.1, since: https://git.libreoffice.org/core/+/d40f2d02df26e216f367b5da3f9546b73f250469 author László Németh <nemeth@numbertext.org> Thu Nov 12 11:33:05 2020 +0100 committer László Németh <nemeth@numbertext.org> Fri Nov 13 16:06:25 2020 +0100 tdf#117643 Writer: fix apostrophe search regression During text search, ASCII apostrophe ' (U+0027) of the search term matches the typographic apostrophe ’ (U+2019) of the text, too. Now 'hi' matches: 'hi' ’hi’ o' matches in: six o’clock seven o'clock and "You know" matches "You know" but NOT „You know” as seen in this attached file. Maybe we could focus this bug on the latter. My Word 2019 matches both apostrophes if the "Use wildcards" option (see: https://cybertext.wordpress.com/2012/01/05/word-find-and-replace-multiple-spaces-before-a-number/) is not checked (by default). Checking this box is not much more unintuitive than checking "Regular expression" in Writer to have only the literal ' or " match. So for UX compatibility (as asked by OP) it would be nice to have "You know" to match "You know" AND „You know”.
Dear László Németh, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
(In reply to Justin L from comment #9) > Like most word processors, LibreOffice by default turns on smart quotes, so > it CHANGES a u+0027 straight single quote into an open or close quote. > > If you copy the 'hi' from the text and paste it into the search, it will > find it. > > It is actually rather DANGEROUS to do what bug 117643 did and have a search > for the straight quote match a smart quote. What if I wanted to find all > the instances where a straight quote was used instead of a smart quote? I > wouldn't be able to do it. So search really ought to find ONLY exactly what > the user entered. > > I would resolve this as WONTFIX, and I would flag commit > d40f2d02df26e216f367b5da3f9546b73f250469 as a regression (although there is > "regular expression" that "fixes" that - which also isn't intuitive to the > average user). Apparently this change has been made and released. It's now impossible in Writer to search for just the plain ascii ' character, as Writer insists on matching smartquote characters as well now. This make it useless for finding erroneous ascii single quote characters to replace with the correct open or close quote. This is in version 7.3.2.2 It's easy to get sections of text without smartquotes if you paste in text from another source. PLEASE fix this. It doesn't matter if I paste the single quote in from the body of the text, a terminal window, or whatever: F&R and plain Find insist on matching any variant. I can see this is a convenience for general use, but having no mechanism for an advanced user to find the character they actually typed to be found, and just that character, is a big loss of functionality. In a long document like mine, it makes F&R useless for finding these kinds of subtle typographical errors in the text. I suppose the workaround will be to revert to a much older version of Writer.
I think there’s a misunderstanding here. It looks like the reporter is trying to find quotes, not apostrophes. It just so happens that the right single quote (U+2019) is the same character as the apostrophe. I checked the attachment from comment 11, and of course they couldn’t reproduce, since they were testing with an incorrectly typeset string (’hi’) that has right single quotes on both sides. When using the correct quotation style (‘hi’), searching for `'` only matches the closing quote. This is the issue. The bug report is confusing because the reporter doesn’t distinguish between apostrophes and single quotes. But what they’re ultimately trying to achieve (find quotes) is a valid request. The fix for bug 117643 was only intended to address apostrophes, so the current behaviour is fully expected. AFAIK there has never been magic matching for quotes (single or double), but I agree it would be good to have. MS Word has it. (In reply to Luke Kendall from comment #13) > It's now impossible in Writer to search for just the plain ascii ' > character, as Writer insists on matching smartquote characters as well now. You’re commenting in the wrong bug. And you can search for exact characters by checking Find and Replace > Other options > Regular expressions.