Created attachment 171304 [details] image showing tha autcorrection option for all languages At Autocorrect options, substitution characters marked to be used at "All" languages are not effective, as at last versions (it works until 7.0 version) it means that autocorrection words must be included at each language used. It's not practical because some expressions as ug (micrograms) or m3 (cubic meters) are useful at all languages.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I don't reproduce this with LO Debian package 7.0.4.2 => regression
Regression from: https://cgit.freedesktop.org/libreoffice/core/commit/?id=ae56dc05b27f05ffcee99845d661a237e70a7a51 author Julien Nabet <serval2412@yahoo.fr> 2021-01-09 20:47:24 +0100 committer Julien Nabet <serval2412@yahoo.fr> 2021-01-10 09:38:23 +0100 commit ae56dc05b27f05ffcee99845d661a237e70a7a51 (patch) tree cbc1c36d71ece12c4ea7d8e259bfcbd8d65176dc parent 94e47e2d90096146f4cd909782d75375d286bed1 (diff) tdf#96787: AutoCorrect: after deleting a replacement entry, it's still used If specific acor<language>.dat exists in "user", don't use the initial one in "share" since the initial one will still contain the deleted entry. See detailed explanation here: https://bugs.documentfoundation.org/show_bug.cgi?id=96787#c21 Change-Id: Ic349159c93d9fc327f38a1d4e8187e3bdc16d08a :-( Not sure how to fix this without breaking tdf#96787, what a mess!
Eike: the patch I had done for tdf#96787 seems wrong. I think adding another block in SvxAutoCorrect::SearchWordsInList (editeng/source/misc/svxacorr.cxx) after first one just to deal with the case "All". However, it seems to correspond to "LANGUAGE_UNDETERMINED" and wouldn't like to interfere with 2 other existing blocks. I noticed you had helped for tdf#58060, thought you might have some idea.
With this patch this one is fixed without breaking the other: diff --git a/editeng/source/misc/svxacorr.cxx b/editeng/source/misc/svxacorr.cxx index ce1f788f593c..21c95bc6bc8d 100644 --- a/editeng/source/misc/svxacorr.cxx +++ b/editeng/source/misc/svxacorr.cxx @@ -1944,6 +1944,20 @@ const SvxAutocorrWord* SvxAutoCorrect::SearchWordsInList( rLang = aLanguageTag; return pRet; } + } + + LanguageTag aLanguageTagUnd(LANGUAGE_UNDETERMINED); + if (m_aLangTable.find(aLanguageTagUnd) != m_aLangTable.end()) + { + //the language is available - so bring it on + std::unique_ptr<SvxAutoCorrectLanguageLists> const& pList = m_aLangTable.find(aLanguageTagUnd)->second; + pRet = lcl_SearchWordsInList( pList.get(), rTxt, rStt, nEndPos ); + if( pRet ) + { + // TODO useful? + // rLang = aLanguageTag; + return pRet; + } else return nullptr; } Now, I'm not sure if it's the right way.
Xisco: I won't be able to fix this one. Should I revert patch from tdf#96787 ? I'm asking the question because if I had to choose between having tdf#96787 fixed and this one fixed, I prefer having tdf#96787 fixed. Of course, just personal opinion.
(In reply to Julien Nabet from comment #5) > Xisco: I won't be able to fix this one. Should I revert patch from tdf#96787 > ? > > I'm asking the question because if I had to choose between having tdf#96787 > fixed and this one fixed, I prefer having tdf#96787 fixed. > Of course, just personal opinion. Hi Julien, Do we really need to choose one or the other? I would rather have both fixed instead. @László Németh, you have done a lot of fixes to the autocorrect, I thought you might be interested in this issue
(In reply to Xisco Faulí from comment #6) > ... > Do we really need to choose one or the other? I would rather have both fixed > instead. Obviously it would be better to have both fixed but I just mean I won't be able to fix this and don't know if someone would like to tackle them in a reasonable delay (not in some months/years :-)). > ...
*** Bug 141951 has been marked as a duplicate of this bug. ***
*** Bug 140739 has been marked as a duplicate of this bug. ***
I'm experiencing the same problem in version 7.1.3.2 x64, Win 10 : all my custom "replace" AutoCorrect options that I configured [All] languages are not applied. As a WORKAROUND I noticed that it works when I switch the language for the text in which the AutoCorrect should be applied to [None]. If the language is already [None] and AutoCorrect does not work, then switching to another language and then back to [None] makes it work for me.
*** Bug 145187 has been marked as a duplicate of this bug. ***
I stumbled upon this bug today when I upgraded from 7.0.4.2 to 7.1.5.2 I can also tell the issue is still present in 7.2.0.0 too.
this is a serious bug... nasty regression and loss of a function many users rely on... I'm still stuck to 7.0.x because of this... has anyone tested it with the latest 7.2.x releasese? 7.2.0 was affected.
At least at 7.2.4.1(x64)MS hasn't been corrected, it's necessary copy all the automatic corrections at all the languages used.
(In reply to Julien Nabet from comment #7) > Obviously it would be better to have both fixed but I just mean I won't be > able to fix this and don't know if someone would like to tackle them in a > reasonable delay (not in some months/years :-)). It is a pity it _is_ taking months to fix this; unfortunately I'm not able to tackle the problem either. It was an elegant feature of LO!
(In reply to KeepTools from comment #15) > (In reply to Julien Nabet from comment #7) > > Obviously it would be better to have both fixed but I just mean I won't be > > able to fix this and don't know if someone would like to tackle them in a > > reasonable delay (not in some months/years :-)). > It is a pity it _is_ taking months to fix this; unfortunately I'm not able > to tackle the problem either. It was an elegant feature of LO! Again, feel free to revert the patch. Personally, I won't do it since I prefer tdf#96787 to be fixed instead of this one. => uncc myself since I don't know how to fix this one (without reverting the patch).
Same bug for me. Downgraded to 7.0.4.2. Too bad! Regarding the bug 96787, my workaround was to delete all the acor_xx-YY.dat files in my profile (not acor_und.dat).
I raised importance from medium to high this is a nasty regression breaking a longstanding working feature of LibO that leads to an important loss of function. many users who rely on the "acor_und.dat" file are now stuck with 7.0.x
Hi László Németh, you did some work in the autocorrection area in the past, I thought you might be interested in this issue
I agree... Laszlo fixed so many annoying bugs about autocorrect... I think he is the most appropriate developer who can try fixing this nasty one
The bug is still present in 7.5.1.1
Affects Linux too, not just Windows. Was "assigned"; back to "new". Still reproducible with a trunk build from today: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 97a38dbfa998967c45efaf3303fedfa1a709a2bb CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 154045 has been marked as a duplicate of this bug. ***
Still present in Version: 24.2.1.0.0+ (X86_64) / LibreOffice Community Build ID: 753981dd0cbbdedeca4fa95681f6d65d370a758f CPU threads: 8; OS: macOS 14.3; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Just switched over to Ubuntu and got hit by this nasty bug. Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Show stopper for me. Back to Windows. :(
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/50be3fa1f0f3b8870af5bda88b65f835ef37d77e tdf#141773 AutoCorrect: fix broken [All] dictionaries It will be available in 25.2.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.
Fixed in master. Back-porting started in 24.8 and 24.2. @Eduardo and all: thanks for the bug report and feedback! Full commit descriptions, including the proposed fix for tdf#96784: tdf#141773 AutoCorrect: fix broken [All] dictionaries This reverts commit ae56dc05b27f05ffcee99845d661a237e70a7a51 "tdf#96787: AutoCorrect: after deleting a replacement entry, it's still used". ======================== tdf#96787 AutoCorrect: find item with ".*" and between :colons: It was very hard to disable autocorrection of (c)->© and other AutoCorrect items, because the searched Replace string "(c)" etc. didn't jump the list cursor to the corresponding ".*(c)" item. Now skip ".*" pattern matching marks, also colon (emoji replacement) characters, so the list cursor jumps to the line ".*(c)"->© typing only "(c" etc., allowing users to press Delete to disable its autocorrection without knowing about the special AutoCorrect patterns. Follow-up to commit 50be3fa1f0f3b8870af5bda88b65f835ef37d77e "tdf#141773 AutoCorrect: fix broken [All] dictionaries".
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/65e755ebeb17d16a84465ba92fe0f8f5ea1aebd9 tdf#141773 AutoCorrect: fix broken [All] dictionaries It will be available in 24.2.5. 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.
Verified in: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5bf58785ba2831de4efc2afe9df463b4a753ccb1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Thank you so much for looking into it, László! :)
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/5c8cda56c138f89396b9fd39cd39cdfc9b92c827 tdf#141773 AutoCorrect: fix broken [All] dictionaries It will be available in 24.8.0.0.beta2. 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.
(In reply to Stéphane Guillou (stragu) from comment #29) > Thank you so much for looking into it, László! :) @Stéphane: Many thanks for your quick review! :)