Created attachment 157759 [details] LO document illustrating the bug Have smart punctuation enabled (I mean, so that typing a space after three periods - ... - the periods are converted to an ellipsis. Steps to reproduce: 1. Delete a comma adjacent to a word, let's call it WORD. 2. Type three periods 3. Type a space 4. Observe that WORD is marked as deleted, and inserted (this is the pointless change mentioned), and more seriously: 5. the deleted comma is also inserted, i.e. its deletion has been reversed See attached file.
I can't confirm it with Version: 6.3.4.2 (x64) Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
Created attachment 157884 [details] Another example document, maybe related? A similar problem occurs even when Record changes are off. In the following sentence, ‘Please’ is in italics, and from the comma onwards – ‘,”’ – Regular. I was disturbed to discover that typing three periods, and then a space to get the smart punctuation to convert the periods into an ellipsis, removed the italics of the ‘Please’. Do you think this bug is related to (or the same as) the above bug? “Please,” began Anika. See the attached file, which adds to the previous version of the example document. I also wonder whether the bug is Linux only. It's odd that it couldn't be reproduced under Windows. Perhaps there's an option or customisation that causes the problem? I went looking for what I referred to as "smart punctuation" but couldn't find anything like that under the Tool->Options menus. I think it's actually set via AutoCorrect. I see I have .*... and … (ellipsis). Maybe the regexp is causing the problem? Hmm, maybe not: changing that AutoCorrect option to .*... -> … made no difference.
I am using Kubuntu 19.04 and trying in my Version: 7.0.0.0.alpha0+ Build ID: 4ff12ba6f4639c73587f2bb58afcc3ca6fb30105 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: kf5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-01-24_21:09:14 Locale: id-ID (id_ID.UTF-8); UI-Language: en-US Calc: threaded but, it can't be reproduce
Luke, I can confirm the second issue with Version: 6.3.4.2 (x64) Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded This doesn't happen, if you add a blank space before typing the three dots. As you can see, it's always difficult to combine two problems in one bug report. So please separate them into two different reports. You can "connect" them, if you add the bug number in "Aee Also".
You are right that inserting a space does avoid this reported bug, for each part: the original issue and the second issue I thought might be related. But when I have change tracking on, I usually forget that LO will introduce a larger change. So I then have to Undo a couple times, insert a space, make the change, then delete the space, all to workaround this bug (and the other). It would be nice if the bug could be fixed and the workaround became unnecessary. I've submitted a separate bug as you suggested (130704) for the 2nd issue, since you think it's probably a separate one. And I see that you must be right if you can reproduce the 2nd issue but not the 1st! Thanks, Dieter.
Note: this requires Tools - Autocorrect - While typing to be activated. Reproduced both on Linux and Windows. In the 4.4 line there was a change. Old behaviour was that three periods were not autocorrected at all, if you typed them after the deleted comma. It should be assumed that the old behaviour masked the problem. The change was https://git.libreoffice.org/core/+/b3b6361c555e54ce852d62c80c0bb3d19c1ec78f%5E!/ fdo#81571 autocorrect doesn't need space before (c), (r), (tm)...
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5a96093f0ecee53432bdf35f247edd6deb501baf tdf#130546 sw autocorrect: don't replace redlining It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
tdf#130546 sw autocorrect: don't replace redlining if it starts or ends within the removed text to avoid various problems, for example, reappearing deleted comma before ellipsis replacement: text[,]... -> text,...[,] or replacing words based on already deleted text: [tt]he -> [tt]the Add test/user-template/user/autocorr/acor_en-GB.dat unit test autocorrect definition with three dots to ellipsis replacement.
Verified in: Version: 7.2.0.0.alpha0+ (x64) Build ID: 761a672d62df1891b9f4f367a499b220ab2b33fa CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded