Created attachment 83714 [details] word deleted from list already still shows up Word Completion does not remove words manually deleted from list. I have set Word Completion to collect words with 7 characters. For previous versions, I was able to delete words from the list that I don't want to appear anymore as I'm typing. For 4.1.0.4, even if I delete the words from the list (by clicking the word and pressing delete key or clicking on Delete Entry), when typing words with the same first three letters as the previously deleted word, that deleted word still appears even if I didn't type it again.
Created attachment 83715 [details] word deleted from list already still shows up
Hi, Thank for your report. I can confirm this. Looks as some caching problem. To reproduce, type (with word completion activated, spell checker off) appeltaart bananenmoes mangoshutney druivensap sinaasappelpulp Remove 'druivensap' from the document Also remove it from the word completion list Now type 'druiv ..' > Word completion shows up
has to be found out in which version the problem poped up for the first time..
(In reply to comment #3) > has to be found out in which version the problem poped up for the first > time.. No need.. I know what is wrong.
Summary edited for clarity.
*** Bug 72200 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > No need.. I know what is wrong. Great - don't hesitate to post a pointer here in case you're to busy with other stuf :)
A "phantom" accumulated Word Completion list persists in memory even when the entire list (as displayed) is blank.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still a problem in Versie: 6.3.0.0.beta1 Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU-threads: 4; Besturingssysteem: Linux 5.0; UI-render: standaard; VCL: gtk3; Locale: nl-NL (nl_NL.UTF-8); UI-taal: nl-NL Calc: threaded
Version where behavior started should be correct before setting bibisectRequest, or at least indicate it' wasn't determined. No repro 3.6.0. Repro 4.0.0. And, if I understand this well, also 6.4+.
I tried bibisect. (LO couldn't start a number of times at the beginning so I skipped it.) Later in Version 3.7.0.0.alpha0+ word is remembered correctly but not offered during typing, so test for this bug is not possible. I skipped that also. Michael, sorry to bother you when I'm not sure, but I don't see other way, since yours is the first bad. Please take a look. $ git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # skip: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect skip e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442 # skip: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f git bisect skip 9daa289e178460daaafa4b3911031df5b8736218 # skip: [387dd1052972d27a3065a249b357e50e0a29829b] source-hash-35836f350861b33a0c28307a413eff76d0433d1e git bisect skip 387dd1052972d27a3065a249b357e50e0a29829b # skip: [19604661a278cb5b1b513d5bcf9e12eb85f4715f] source-hash-f05861de995f8d4edb1a97c616d050f55ec04c32 git bisect skip 19604661a278cb5b1b513d5bcf9e12eb85f4715f # bad: [4d8d18a8c871d6803af99b706f780eb6e65c7a5d] source-hash-d4779887636fa9ab5b477f3436bcd3728a3e30ba git bisect bad 4d8d18a8c871d6803af99b706f780eb6e65c7a5d # skip: [66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa] source-hash-21dd191b9fd5a75f7633ea27f745a347adb42ae3 git bisect skip 66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa # skip: [80860139a96019d7487e02c7b488a8990e1e524f] source-hash-27d3fc221d042decbd84b72719107547562d2e12 git bisect skip 80860139a96019d7487e02c7b488a8990e1e524f # bad: [bc687bf6bc5604c51680e798536ccbf35fa0c6b8] source-hash-1692cf6854ff7adbb2bd47f2f7ec2b3de51864f3 git bisect bad bc687bf6bc5604c51680e798536ccbf35fa0c6b8 # good: [c6a69c23e32b372e1f279f1a5ea6aa0a6cf52968] source-hash-cac1f33e839469d884730350e46a21d92fb442f2 git bisect good c6a69c23e32b372e1f279f1a5ea6aa0a6cf52968 # bad: [21334bea86b7167cacd2c436f91b405fcdc83b98] source-hash-934e051b16349a1ab6d2bdd9f03e60aaafcb2ec8 git bisect bad 21334bea86b7167cacd2c436f91b405fcdc83b98 # good: [8a290d6041441ba8836da4ad65d33efcd00a2716] source-hash-cfec62ef443b3cda054bb698375ee49bc11586a0 git bisect good 8a290d6041441ba8836da4ad65d33efcd00a2716 # good: [173f32b96a0224f28f311adf21d65f4d4e98dfa1] source-hash-22cf0759547aa1803f77dbd3ee91774600dadc6f git bisect good 173f32b96a0224f28f311adf21d65f4d4e98dfa1 # skip: [7d63b17e3d3fe488e34de32ffa042559dbad3cfd] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435 git bisect skip 7d63b17e3d3fe488e34de32ffa042559dbad3cfd # bad: [0e54cced22ee8d216a783202cf26384317db0959] source-hash-2815396a1813cb3956c5aba066de49a7f34bc657 git bisect bad 0e54cced22ee8d216a783202cf26384317db0959 # skip: [18518588d8414f446ece5591944766f5082ebef5] source-hash-82c25249e624cb54ca6d3293d1c3d0d8ebc208e0 git bisect skip 18518588d8414f446ece5591944766f5082ebef5 # skip: [489397741e799a5ad767e4b12be827c8c96ba60b] source-hash-50b4cbe94e200288d57a135bc9386012164bc726 git bisect skip 489397741e799a5ad767e4b12be827c8c96ba60b # skip: [a035fba5e34dc12e2b1796af6ec46f04647a3576] source-hash-df9b0d2e930eb1f60e429301e5386f742a1676ff git bisect skip a035fba5e34dc12e2b1796af6ec46f04647a3576 # good: [a429a2e082aeb9bff36833603d8deb55385c7905] source-hash-b8fa8841c098f15ef2280aa4c82c55c4f96325c9 git bisect good a429a2e082aeb9bff36833603d8deb55385c7905 # only skipped commits left to test # possible first bad commit: [0e54cced22ee8d216a783202cf26384317db0959] source-hash-2815396a1813cb3956c5aba066de49a7f34bc657 # possible first bad commit: [7d63b17e3d3fe488e34de32ffa042559dbad3cfd] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435 # possible first bad commit: [a035fba5e34dc12e2b1796af6ec46f04647a3576] source-hash-df9b0d2e930eb1f60e429301e5386f742a1676ff # possible first bad commit: [18518588d8414f446ece5591944766f5082ebef5] source-hash-82c25249e624cb54ca6d3293d1c3d0d8ebc208e0 # possible first bad commit: [80860139a96019d7487e02c7b488a8990e1e524f] source-hash-27d3fc221d042decbd84b72719107547562d2e12 # possible first bad commit: [489397741e799a5ad767e4b12be827c8c96ba60b] source-hash-50b4cbe94e200288d57a135bc9386012164bc726 0e54cced22ee8d216a783202cf26384317db0959 is verified bad. With git checkout HEAD^1 word is remembered but not offered. I guess that makes it suspicious. https://gerrit.libreoffice.org/plugins/gitiles/core/+/2815396a1813cb3956c5aba066de49a7f34bc657%5E!/ commit 2815396a1813cb3956c5aba066de49a7f34bc657 [log] author Michael Stahl <mstahl@redhat.com> Tue Jul 31 17:25:44 2012 +0200 committer Michael Stahl <mstahl@redhat.com> Tue Jul 31 20:26:45 2012 +0200 tree 2d2699d458cee9af16532a758e66e12befc3f08a parent b60285e916e1c4102ef990f9aacb85307973d55e [diff] _SetGetExpFlds: this looks simpler with upper_bound Change-Id: I37dd291aaa229493141fbb8b426488e8e4427185 Others are: https://gerrit.libreoffice.org/plugins/gitiles/core/+/83837d6514217c82ebe8d56dddf89fa34f4b5435%5E!/ commit 83837d6514217c82ebe8d56dddf89fa34f4b5435 [log] author Tor Lillqvist <tml@iki.fi> Mon Jul 30 12:24:41 2012 +0300 committer Tor Lillqvist <tml@iki.fi> Mon Jul 30 12:25:14 2012 +0300 tree d8f9bf6d7c3cde4dc3afe479c990c4a21e41a500 parent 442b57834aa4e01b832cad42b2b466e8cb2a94a8 [diff] The 'r' in unxandr stands for ARM Change-Id: I5b6e713c130dc52f00d0d1e941ae856e8a3b7e7e https://gerrit.libreoffice.org/plugins/gitiles/core/+/df9b0d2e930eb1f60e429301e5386f742a1676ff%5E!/ commit df9b0d2e930eb1f60e429301e5386f742a1676ff [log] author Arnaud Versini <arnaud.versini@gmail.com> Sat Jul 28 17:56:59 2012 +0200 committer Arnaud Versini <arnaud.versini@gmail.com> Sat Jul 28 17:59:01 2012 +0200 tree e629b4feb1be13fd5b233c4bc9f6687e87ce73de parent 36aae9cda39e08c450ecef048f763bdd023d03a2 [diff] Use memcmp insteadof rtl_compareMemory in sw Change-Id: Ie3a95f628387756d2fa941707bd5e224b41b5720 https://gerrit.libreoffice.org/plugins/gitiles/core/+/82c25249e624cb54ca6d3293d1c3d0d8ebc208e0%5E!/ commit 82c25249e624cb54ca6d3293d1c3d0d8ebc208e0 [log] author Caolán McNamara <caolanm@redhat.com> Fri Jul 27 14:11:08 2012 +0100 committer Caolán McNamara <caolanm@redhat.com> Fri Jul 27 14:37:00 2012 +0100 tree 098de08481289c24e629a358f4dc523c245fc432 parent 8eeddcdbb5baac2ee3378df38a198b0cdffa0495 [diff] list dependencies explicitly and make the list (by its makefile proxy) a dependency of the output so that removing an entry will trigger a rebuild of the target and incremental builds are possible Change-Id: I18c8d5ea2140e61b2ef78e256871402be94b79e2 https://gerrit.libreoffice.org/plugins/gitiles/core/+/27d3fc221d042decbd84b72719107547562d2e12^!/ commit 27d3fc221d042decbd84b72719107547562d2e12 [log] author Michael Stahl <mstahl@redhat.com> Thu Jul 26 15:53:28 2012 +0200 committer Michael Stahl <mstahl@redhat.com> Thu Jul 26 15:54:50 2012 +0200 tree acefbbf90724b084c04b1bbc5b668c5fed0ee3f4 parent 772699ac1f2375c33f0819ebb127555d3178c4e5 [diff] warning C4018: '>': signed/unsigned mismatch Change-Id: I25607ce79111b2c2933ab5e2c165df0594ed4363 https://gerrit.libreoffice.org/plugins/gitiles/core/+/50b4cbe94e200288d57a135bc9386012164bc726 commit 50b4cbe94e200288d57a135bc9386012164bc726 [log] author Kohei Yoshida <kohei.yoshida@gmail.com> Wed Jul 25 09:47:15 2012 -0400 committer Kohei Yoshida <kohei.yoshida@gmail.com> Wed Jul 25 15:02:32 2012 -0400 tree a010390d66704d120d782a0e6f7f45bae6cf1217 parent df8a15d87778faaad6c35a98af9563a217951d47 [diff] More on sal_Bool to bool. Change-Id: I31694bf8487db08a1cc7b7de2b18a7d5959d81d1
Still living in Version 6.4.6.2. A web search on the problem yields next to nothing. Only a persistent end user, by posing a question directly at ask.libreoffice.org, can get an indication of why they are getting phantom word completion tips. Any chance this bug can get fixed after 7 years, pretty please?
*** Bug 145096 has been marked as a duplicate of this bug. ***
I'm not sure if this is the right place, but I created an account just post this message. Some years back I used Open Office, and the auto complete feature there worked really well. I remember how it was normal to press enter in almost every sentence and typing was significantly sped up using auto complete. When I switched to Libre Office, I lost this habit, and I've tried to think about why. I think there are at least two reasons. The first, and I think primary reason, is that Libre Office shows the suggested completion in a little box above the text, while Open Office was showing the suggested completion as what it would look like if I would have just continued typing (only with a different shade). This difference is significant. The eyes are focusing on where the cursor is, and on the continuation of the line. It's not at all as easy to switch visual focus to a box above the line. I feel that it somehow disturbs the visual flow. The second problem is connected to this bug report, but I think not only that. I don't know how the completion choice algorithm works, but it seems to be working pretty badly. It tends to choose weird long strings such as URL:s or other weird strings it must have seen in some document. But these suggestions are completely unlikely to be what one is looking for. The choice algorithm should make some kind of probability estimation, it doesn't even have to be advanced: The most frequent word with a specific prefix is the most probable continuation. Someone mentioned that it is possible to choose between completions with tab or something, but this would be a useless option. One has to remember that typing for most of us is already pretty fast. Having to go through alternative completions would defeat the purpose. Finally, I believe that these functional weaknesses in how Libre Office implements auto completion, is the reason that this bug is getting little attention. Fixing this particular bug isn't enough to make it the valuable feature that I remember that it was in Open Office. But maybe it would be possible for Libre Office to look at how auto completion worked in Open Office and just copy how the feature worked there, because I remember that it was really good.