Re: [Pan-users] Spellchecking

[Torstein Sunde]

Charles Kerr wrote:

>  Gene Ward Smith wrote:
> > What is the most expeditious way to add spellchecking to pan?
> 
> I'd advise against it.
> The ispell/pspell/aspell/gtkspell install chain isn't worth the pain.

We don't use ispell for Pan, do we?

> There's been a huge thread on c.o.l.a about this recently, which
> has got me looking at spellchecking again.

I suppose you're referring to the thread started by T. G. Reaper on
March 24?  It looks to me that he probably:
- Used an RPM without spellchecking compiled in.  (At least it looks
  like that's the case for the RPMs for SuSE 8.1 in
  ftp://ftp.suse.com/pub/people/drahn/)
- Used a gtkspell RPM not compiled for SuSE.  (There are none at
  rpmfind.net.)  That's probably the reason for the GTK+/GTK2
  naming conflicts.
Anyway, an advocacy newsgroup is hardly the best place looking for
help...

> After 0.14.0 is out the door I'm going to fix this by having only
> one prerequisite for spellchecking: aspell >= 0.50:
> 
> * aspell 0.50 is basically a merging of aspell & pspell,
>   so the pspell prerequisite drops out.
> * gtkspell is only a few hundred lines of source code,
>   so I can just bundle that along in Pan and add a credit
>   to Evan Martin.

Then I fear that we may move the dependency hell from gtkspell to Pan.
Maybe only using aspell > 0.50 solves the problem, but are you certain
that there won't be problems if Pan is compiled against a different
version of the C++ libraries than aspell?  (Or is the interface of
the new aspell independent of C++ or other nasty dependencies?)

Currently, it's fairly easy to use the same Pan RPM across several
releases of a distro.  (But see my posting on pan-devel on March 24 for
some annoyances).

Gtkspell, on the other hand, apparently needs to be built for each
release of a distro.  Binary incompatibility between C++ libraries is
probably one of the reasons, the aspell 0.33 to 0.50 transition is
likely to become another.  We could risk this happening to Pan.

Unfortunately, not that many distros come with gtkspell (judging from
rpmfind.net), so the Pan packager needs to provide gtkspell packages as
well.  But then, gtkspell will need to be updated much less frequently
than Pan.

After having a brief look at some of the gtkspell source code, it
appears that it lacks a function for getting a list of available
dictionaries, alternatively a dialogue that lets the user select a
dictionary from those available.  Without such a function, Pan will
anyway need to call aspell directly in order to let the user switch
dictionary.  (Maybe it's possible to steal some code from gedit,
sylpheed-claws or balsa for this purpose?)

BTW, instead of bundling the source code, could linking gtkspell
statically be an option?  That contradicts some of my concerns, but at
least it makes it easier to apply recent bugfixes in gtkspell, as long
as the packager makes sure he's using the latest release.