Created attachment 117325 [details] screenshot spin-off of Bug 92774 Where a short acronym (2 or 3 letters) is not in the dictionary, right clicking may produce a very long list of autocorrect options. It is necessary to scroll down to the options for handling this - ignore, add to dictionary etc. as you may see in the screenshot the amount of autocorrect suggestions is so long that makes very annoying tanf time consuming to scroll down trough the list to reach the option items. so, I think it would be better to limit the number of those autocorrect suggestions (I think 20 would be enough) in order to avoid the scrolling and always have to options items always at reach
reproducible even in older versions, at least up to 3.6.0 but I suspect is inherited from OOo
I confirm that this could do with improvement, either by arbitrarily limiting the number of choices offered or, perhaps better, to review the logic behind the offered suggestions. For example, putting dwp into LO generates a screenful of options. In Word 2010 (only when I must...) just 5 options are offered.
If I understand well, it has nothing to do with auto-correction. It is not auto-correct suggestions but correct spelling suggestions. Best regards. JBF
@JBF I do not agree. if you select one of those suggestions, LibO will correct the typed word with that choice. if you wanna that LibO reminds that replacement for the next time you type it you have to select one of the bottom menu items which is "Always correct to" which reopens the same list. in both cases, dealing with such long lists is annoying and unproductive... from my experience is unlikely that the desired autocorrect replacement will be in the last items of the list... as said before 20 would be enough...
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
still present in LibO 5.1.5.2
Created attachment 127825 [details] The Hunspell driven spellcheck & autocorrect popup with just English dictionary @tommy27, * Is this an integration issue with Hunspell? On WIndows 10 Pro with 5.2.2 and *only* the en-US dictionary installed. If using the same "Hk" digraph I get a sane list of alternates that actually relate to the digraph entered (attached). The clips you show seem to have really strange suggestions, as if the replacements are being pulled from dictionaries for multiple languages without regard for the language of the paragraph. What shows for you with cursor on the "Hk" digraph and entering the F7 "Spelling and Gramar:" dialog? What other entries are in the "Text language" list box?
Created attachment 127826 [details] Hunspell driven F7 dialog for "Hk" search The Hunspell driven F7 "Spelling and Grammar" dialog for the same "Hk" search.
Created attachment 127827 [details] F7 dialog here it is
With 8 entries already in the main context menu, the suggestion list should likely not exceed 10 entries. For users who want more suggestions, they have easy access to jump into the spelling or autocorrect dialogs from the context menu. If more entries are wanted to be shown, maybe a more submenu entry can appear at the bottom of the suggestions, but this shouldnt have more than 20 entries in it. The autocorrect submenu can have 20 entries in it, if wanted.
hi jay, is something you are able to tweak? as seen in my screenshot, sometimes the list of suggested entries is really too long. I agree we should limit it to a number between 10 and 20.
hey tommy, nope not likely something i can tweak. :( So lets pass it on to the devs. :)
No, the problem with an artificial limit to the number of lookups is that the source "dictionary" can not qualify the match--so there is good chance the match needed will not show at the top of the list before filtering. The list needs to be complete--and a "more" button or scroll provided to keep the lists height constrained. The other problem seems to be that currently the Hunspell dictionary and grammar checker is not filtering out the candidate matches. We get selections from all installed dictionaries/word lists--but the result should be limited. Seems it should by default return matches from the dictionary/thesaurus for the selected language of the paragraph being entered, or maybe that of the document. But not return matches from all installed dictionaries/word lists as it seems to be doing now.
(In reply to V Stuart Foote from comment #13) > No, the problem with an artificial limit to the number of lookups is that > the source "dictionary" can not qualify the match--so there is good chance > the match needed will not show at the top of the list before filtering. The > list needs to be complete--and a "more" button or scroll provided to keep > the lists height constrained. Having an endlessly scrolling list to show ever possible lookup match would be bad UX in my view and against the easy access concept of the context menu. > The other problem seems to be that currently the Hunspell dictionary and > grammar checker is not filtering out the candidate matches. We get > selections from all installed dictionaries/word lists--but the result should > be limited. Yep that seems to be the major issue here of it not removing duplicates. > Seems it should by default return matches from the dictionary/thesaurus for > the selected language of the paragraph being entered, or maybe that of the > document. But not return matches from all installed dictionaries/word lists > as it seems to be doing now. Yes it should only bring results based on the selection else the paragraph, as we have the 'Set Language for Selection' and ''Set Language for Paragraph' entries in the context menu, and the red underline only shows up based on these two settings.
** 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
*** Bug 124436 has been marked as a duplicate of this bug. ***
still present in LibO 6.4.2.2
still present Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ad7a84e41b50e6221634307112f00baf2b549dcd tdf#92824 spell checking: limit suggestions only for the best ones It will be available in 7.6.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.
Commit description: tdf#92824 spell checking: limit suggestions only for the best ones Apply Hunspell fix to keep only the best suggestions, if they exist to avoid of overgenerating worse suggestions especially for short bad words. See Hunspell commit b88f9ea57bdb9b219f3c1d2c67f4f882f1f23194 "Keep only REP, ph: or 2-word dictionary phrase suggestions These are the best suggestions, no need to search other ones to avoid annoying redundant and long list. For example to suggest only "a lot" to the bad form "alot", add the 2-word phrase "a lot" to the dic file. Or for a very typical spelling mistake, enough to specify the bad form with a ph: in the dictionary file to remove the other suggestions."
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/9fe6a9406d705ddd23ec78202950fb4761521df2 tdf#92824 spell checking: limit suggestions only for the best ones It will be available in 7.5.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.