Exorcising KSpell

[Don Sanders]

On Monday 02 February 2004 13:26, Zack Rusin wrote:
> Ave,
>
> after almost 7 years it's time to replace kspell. We had and still
> have a lot of problems with the current implementation. The
> asynchronous nature of the library and the fact that binaries
> (ispell/aspell/hspell) it uses often have different options makes
> it almost unmaintainable. Those problems apply both to kspell and
> kospell.
>
> Currently the best replacement option is kspell2. It's a completely
> new library addressing all issues we had with kspell and kospell.
> 1) It's synchronous - no more guessing whether the process hangs,
> whether we fed too much to it or whether something broke - you get
> results instantaneously.

Great. It required a lot of effort to work around these issues for 
as-you-type spell checking.

> 2) Multiple dictionaries per document - you can spell check a
> document in multiple languages. Will be incredibly useful in KMail,
> where email can be in part in a few languages.

Nice.

> 3) Everything is in process - kspell2 doesn't use any binaries or
> kprocio. You need either aspell-devel package or just ispell
> dictionaries.

Cool. Hopefully this eliminates the ongoing reliability problems with 
kspell.

> 4) It's plugin based instead of being monolithic - currently aspell
> and ispell plugins are there. hspell and myspell will be added. 5)
> Text feed is filtered - there were many problem with spell checking
> html or tex document. KSpell2 introduces concept of filters which
> you pass to the spell checking dialog. Filters deal with the buffer
> and give the spell checker words to spellcheck. So now we can
> easily add a spell checker to Kate that would check only the actual
> strings instead of the code.

Is the concept of filters compatible with QSyntaxtHighlighter? Does 
this address the issue of spell checking rich text documents?

I'm due to think about KMail html editing and as-you-type spell 
checking this weekend. If possible I would like to deliver html 
editing with spellchecking for the separate kdepim release, (but I 
suspect it will be difficult).

> As far as the library we'd have to figure out how to and where to
> move this stuff. KSpell needs to be kept as long as we're having
> bc, kspell2 lives in a namespace so it can safely live along
> kspell. (btw kspell2 is in kdenonbeta/kspell ). The following files
> don't use _any_ gui classes:
> kspell_broker.[h,cpp] , kspell_client.[h,cpp], kspell_dictionary.
> [h,cpp], kspell_config.[h,cpp], kspell_filter.[h,cpp]. Then there
> are two plugins and kspell_dialog.[h,cpp].
>
> I'd like to start switching with koffice because David is assigning
> some of its bugs to me and I don't drink so they get me close to
> crying every single time.
>
> Besides come on, don't you wanna have the on-fly spell checking
> working correctly/reliably for a change?

Hmm, I believe on-the-fly spell checking is working correctly, 
reliably and performing well for the 3.2 release. At least I'm not 
experiencing problems with it (are you?).

Having said that if you can replace kspell in a way that doesn't break 
existing applications that would be great I'm all for it. IMO the (1) 
reason you state above alone is enough reason to replace kspell.

Don.