[Libreoffice-bugs] [Bug 96787] AutoCorrect: After Removal of Replacement Entry the Replacement Itself is still Performed.

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=96787

Julien Nabet <serval2412 at yahoo.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |dirk.wun at t-online.de,
                   |                            |serval2412 at yahoo.fr
           Assignee|libreoffice-bugs at lists.free |serval2412 at yahoo.fr
                   |desktop.org                 |

--- Comment #21 from Julien Nabet <serval2412 at yahoo.fr> ---
On pc Debian x86-64 with master sources updated today, I could reproduce this.

I tried with the example of tdf#139377 where Dirk (I put in cc) would like to
avoid LO from replacing "daß" by "dass".
After deleting the entry, LO still does the replacement even after having
restarted LO.

If we take the example of German language from Germany, the initial replacement
file (ie with a brand new LO profile) is "acor_de.dat" present in "share"
directory.

Just for information, these dat files are in fact zip files with a specific
structure, see:
julien at debianamd:/tmp/test$ ls
acor_de.dat
julien at debianamd:/tmp/test$ mv acor_de.dat acor_de.zip
julien at debianamd:/tmp/test$ unzip acor_de.zip 
Archive:  acor_de.zip
 extracting: mimetype                
  inflating: DocumentList.xml        
  inflating: META-INF/manifest.xml   
  inflating: SentenceExceptList.xml  
  inflating: WordExceptList.xml      


When deleting an entry in the autocorrect dialog and click Ok, LO generates
a "acor_de-DE.dat" in "user" directory this time.
This "acor_de-DE.dat" contains all the replacements from "acor_de.dat" except
the deleted entry.
Important thing to note: "acor_de.dat" in "share" doesn't change and still
contains all replacements (included "daß"=>"dass")

Remark: the extra "-DE" in the file name is because I used Germany locale. If I
switch to Austria locale for example, it will use initial "acor_de.dat" from
"share" so it won't use "acor_de-DE.dat" from "user" directory)

After some debugging, I noticed that the type of replacement "daß"->"dass" was
done in SvxAutoCorrect::SearchWordsInList
(see
https://opengrok.libreoffice.org/xref/core/editeng/source/misc/svxacorr.cxx?r=40e98c87#1920).

1) it begins in the block:
   1932     // First search for eLang, then US-English -> English
   1933     // and last in LANGUAGE_UNDETERMINED
   1934     if (m_aLangTable.find(aLanguageTag) != m_aLangTable.end() ||
CreateLanguageFile(aLanguageTag, false))
   1935     {
   1936         //the language is available - so bring it on
   1937         std::unique_ptr<SvxAutoCorrectLanguageLists> const& pList =
m_aLangTable.find(aLanguageTag)->second;
   1938         pRet = lcl_SearchWordsInList( pList.get(), rTxt, rStt, nEndPos
);
   1939         if( pRet )
   1940         {
   1941             rLang = aLanguageTag;
   1942             return pRet;
   1943         }
   1944     }

gdb showed that pList.get() used "acor_de-DE.dat" (from "user") and when
searching "daß", it doesn't enter if block at line 1939 as expected.

2) But then LO keeps in the next block:
   1946     // If it still could not be found here, then keep on searching
   1947     LanguageType eLang = aLanguageTag.getLanguageType();
   1948     // the primary language for example EN
   1949     aLanguageTag.reset(aLanguageTag.getLanguage());
   1950     LanguageType nTmpKey = aLanguageTag.getLanguageType(false);
   1951     if (nTmpKey != eLang && nTmpKey != LANGUAGE_UNDETERMINED &&
   1952                 (m_aLangTable.find(aLanguageTag) != m_aLangTable.end()
||
   1953                  CreateLanguageFile(aLanguageTag, false)))
   1954     {
   1955         //the language is available - so bring it on
   1956         std::unique_ptr<SvxAutoCorrectLanguageLists> const& pList =
m_aLangTable.find(aLanguageTag)->second;
   1957         pRet = lcl_SearchWordsInList( pList.get(), rTxt, rStt, nEndPos
);
   1958         if( pRet )
   1959         {
   1960             rLang = aLanguageTag;
   1961             return pRet;
   1962         }
   1963     }

and here pList.get() shows "acor_de.dat" from "share".
So when searching "daß", it finds the replace (since "acor_de.dat" isn't
changed when deleting an entry)

I'm gonna propose this straightforward patch:
diff --git a/editeng/source/misc/svxacorr.cxx
b/editeng/source/misc/svxacorr.cxx
index ae6dceb33adf..0f048114462b 100644
--- a/editeng/source/misc/svxacorr.cxx
+++ b/editeng/source/misc/svxacorr.cxx
@@ -1941,6 +1941,8 @@ const SvxAutocorrWord* SvxAutoCorrect::SearchWordsInList(
             rLang = aLanguageTag;
             return pRet;
         }
+        else
+            return nullptr;
     }

     // If it still could not be found here, then keep on searching

If a correspond acor file is found in user, it goes into 1) like previously but
instead of keeping on with 2), if there's no replacement found, it returns
nullptr.

I tested this patch with a brand new LO profile (so without "acor_de-DE.dat"),
the replacement works since we don't enter the first if of 1) and so we go into
2).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210109/0a7aeb86/attachment.htm>