Bug 386611

Summary: Language auto-detection causes some words to be incorrectly marked as misspelled
Product: [Frameworks and Libraries] frameworks-sonnet Reporter: reescf
Component: generalAssignee: Martin Sandsmark <martin.sandsmark>
Status: REPORTED ---    
Severity: normal CC: a.samirh78, adrian, daniel, Flupp+bugs.kde.org, frederick888, kdelibs-bugs, nate
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description reescf 2017-11-07 02:09:44 UTC
Spell-checking no longer works to either underline incorrectly spelt words or to not underline correctly spelt words. The choice of dictionary appears to be almost entirely ignored, except for at the broadest level of choosing one language rather than another. (And it does not work consistently even then.)

I have configured the default dictionary in both KDE settings and in Kile as British English with -ise endings and accents. I believe this corresponds to aspell's en_GB-ise-w_accents.multi.

The problem is not in aspell: spell-checking a sample file on the command line with aspell works as expected. (Words are marked as incorrect if and only if not in the dictionary.)

In Kile, however, words in the dictionary are marked as incorrect and words not in the dictionary are not marked as incorrect. Incorrectly marked incorrect words offer to replace the word with an identical one. That is, the contextual menu for spelling includes the current word in the list it offers of possible corrections. Sometimes choosing this word again causes it to be recognised as correct. More usually, 'replacing' it still leaves it marked as incorrect. Kile seems to particularly dislike the word 'which', but there is no consistency here really.

In addition, words which are present in other English dictionaries, but not the dictionary selected, are not marked as incorrect (unless they are one of the words Kile just doesn't like and underlines regardless). 

Here's an example:

echo "flavor flavour flavoring flavouring honor honour color colour recognize recognise" | aspell -l en_GB-ise-w_accents -a
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.6.1)
*
*
& flavoring 10 15: flavouring, flavourings, favouring, flaring, flooring, slavering, flavouring's, flouring, florin, Florine
*
& honor 35 36: ho nor, ho-nor, hon or, hon-or, honour, honer, hone, Hon, hon, donor, hornier, Hanoi, honey, Horne, honours, Horn, hoing, horn, horny, nor, Ono, honers, honker, Han, Hun, hen, Hong, hoar, hoer, honk, hons, hour, hon's, honour's, honer's
*
& color 35 49: col or, col-or, colour, Colo, Coole, cool, Cole, cooler, COL, Col, col, collar, COLA, cloy, cola, coll, Cooley, Colon, colon, coolie, Cleo, Clio, coil, coley, colours, coal, cowl, Cl, cl, coo, cools, cor, coolly, colour's, cool's
*
& recognize 4 62: recognise, recogniser, recognised, recognises
*

Given the same list of words with the same dictionary, Kile marks as incorrect: flavour flavouring honour colour and recognise. It does not mark as incorrect: flavor flavoring honor color or recognize.

Expected: Kile should mark flavoring honor color and recognize as incorrect. It should not mark flavor flavour flavouring honour colour or recognise as incorrect. That is, it should mark as incorrect all and only words aspell marks as incorrect when using the same dictionary. 

Dictionary name configured in Kile's settings: "British English (United Kingdom) [-ise suffixes with accents]".

Relevant section of ~/.config/kilerc:

[Spelling]
backgroundCheckerEnabled=true
checkUppercase=true
checkerEnabledByDefault=true
defaultClient=
defaultLanguage=en_GB
skipRunTogether=false

Note that no dictionary is specified here. This does not seem to be recorded anywhere for Kile specifically. However, 

grep dictionary .config/kate*

returns

.config/katemoderc:Variables=kate: current-line-color #c0c0c0; default-dictionary en_GB-ise-w_accents; font Source Code Pro [ADBO]; indent-mode latex; replace-tabs true; replace-tabs-save true; syntax LaTeX;

Details of my environment etc. are included in a thread at https://bbs.archlinux.org/viewtopic.php?id=231431. (I don't suppose they are relevant here, so I won't repeat them, but give the link just in case.) 

KDE forum topic with posts by two other users having the same problem: https://forum.kde.org/viewtopic.php?f=66&t=140513&p=376745&hilit=kile#p376745. (The topic title suggests the problem is specific to UK English, but the responses to the initial post make clear that the issue occurs for non-English spell-checking as well.)

I found some previous bugs reporting similar problems. However, none of those appeared to match the details of the issue I'm seeing. The problem I'm seeing is not with aspell - aspell works fine - and it is not something resolved by an earlier update of KDE/Kile. Rather, this is a problem I'm seeing for the first time with the new QT5-based version of Kile in Plasma 5. In fact, recent updates to Plasma appear to have exacerbated the problem, if anything.

It would be much appreciated if a response to this report could indicate whether this is likely to get fixed shortly or not, as I need to know whether I should switch to another editor. Spell-checking is a deal-breaker for me. I can spell-check at the command line if a fix is coming soon, but that's a pain. So if no fix is likely or likely soon, I should find an alternative editor.

I would be happy to provide further information, if somebody tells me what might be helpful.
Comment 1 Michel Ludwig 2017-11-07 04:39:38 UTC
Can you try disabling the language auto-detection feature in the editor settings in Kile to see whether that changes anything?
Comment 2 reescf 2017-11-08 01:04:16 UTC
(In reply to Michel Ludwig from comment #1)
> Can you try disabling the language auto-detection feature in the editor
> settings in Kile to see whether that changes anything?

*Extremely minimal* testing suggests this will indeed help. Do note that all I've done is disable that feature and paste the list of words from my example into the currently active document. So, when I say 'minimal', I really do mean minimal. However, Kile marks as incorrect flavoring, honor, color and recognize - and nothing else. 

If this works - so simple - I will be firmly in your debt!
Comment 3 reescf 2017-11-11 21:07:10 UTC
(In reply to Michel Ludwig from comment #1)
> Can you try disabling the language auto-detection feature in the editor
> settings in Kile to see whether that changes anything?

Unfortunately, further testing suggests this is not going to solve the problem. Now on-the-fly spell-checking doesn't work at all. If I want to spell-check, I need to disable and re-enable the feature. This then underlines incorrect words. If I then change one of the incorrectly spelt words, it is no longer marked as incorrect - no matter what changes I make to it. (E.g. sticking another 'j' somewhere makes it correct, it seems.) Moreover, nothing newly entered is spell-checked. Again, I can switch the feature of and on again using the menu and then it will underline words appropriately. This includes e.g. 'color' and 'recognize' being marked as incorrect, but not 'colour', 'recognise' etc. But it doesn't underline, say, 'xswereqtr' as incorrect if I add that - not until I disable on-the-fly checking and re-enable it. Then it marks 'xswereqtr', but if I append a 'q' - so I now have 'xswereqtrq' - it removes the underlining, even though it is obviously still incorrect.
Comment 4 reescf 2017-11-12 23:34:15 UTC
Should I open a separate bug for the new issue? Or is it the same bug as the original problem?
Comment 5 Michel Ludwig 2017-11-14 15:00:18 UTC
Can you try the hunspell back-end, for instance?

I suspect there could be an issue with how aspell is interfacing with sonnet.
Comment 6 reescf 2017-11-30 18:39:56 UTC
I can't reproduce the follow-up issue now. With auto-detection off, spell-checking seems to be working - thanks.
Comment 7 Adrián Chaves (Gallaecio) 2018-04-16 19:48:50 UTC
Damn it, it is indeed the automatic detection that causes the issue. Would it be too crazy to suggest removing the feature altogether for the time being, and opening a bug to provide it back (assuming someone actually wants it)?
Comment 8 Ahmad Samir 2018-12-31 17:44:28 UTC
*** Bug 380461 has been marked as a duplicate of this bug. ***
Comment 9 Daniel M 2024-11-05 20:21:43 UTC
Can confirm this behavior and workaround in 2024 with KWrite.  Does it make sense to open a new issue?