Re: [aspell-devel] Loadable Filters and Context scipping

[Kevin Atkinson]

Hi,

Thank you for offering to add loadable filter support.

Don't even look at Aspell .33.7 it is outdated and no longer maintained.  
The filter interface has been completely rewritten for Aspell 0.50.

Also please not that there is already some support for loadable filter
support in the CVS version of Aspell thanks to Sergey Poznyakoff, but its
not finished yet.  Here is what is there:

  The support for loadable filters is enabled if the underlying OS
  supports dlopen() calls. The sample filter for .po files is provided
  in examples/po-filter.c. To spell check the supplied es.po, run:

  export LC_ALL=es_ES
  aspell --add-filter=loadable
         --loadable-name=<path-to-local/aspell>/po-filter.so check po/es.po

  Currently --loadable-name requires a full pathname to the .so module.
  I plan to add path-searching features later.

And here is what I would like to eventually see:

1) Automatic loading of filters, ie when a user specified
   "--add-filter=foo" Aspell will first see if there is a built in filter
   "foo" and if not it will try to load it.  The loadable filter should
   not be needed.

2) Allow setting of options for the loadable filters where the options are
   of the form "<filter>-<option".  This can be done in one of two ways.

    1) Automatically allow all options of the form *-* to be set even if
       the option is not known.  When the option is retrieved,
       and after the filter module is loaded the config class will check
       if it is valid.

    2) When an option <a>-<b> is set and is not known by the config
       class it should look for a special data with its name based
       on <a>.  If it can find one it should load the list and then
       check if the option is valid.  If it can't find one it will
       report that the key is not known.

  #1 is the easiest but suboptimal because 1) the config class will have
  to accept any options with a dash in them and 2) if the value is invalid
  it will only be reported when the option is retrieved, not when the
  option is set.  #2 would be the best but it would be more difficult to
  pull off.  Part of the problem is that when config sees an option of the
  form <a>-<b> it is diffacult for it to tell if it is corresponds to the
  option "<a>-<b>" or if it corresponds to option <b> for module <a>.

If you are interested in picking up where he let off please let me know.

Thanks again.

-- 
http://kevin.atkinson.dhs.org