Document how to add providers

[norayr]

hello, people,

i am trying to understand, how to add a new custom backend to enchant.

will it just search for shared object library at some path and load it automatically, or in order to add a custom backend the enchant source has to be modified?

also can you point to the API one needs to implement when preparing a new backend.

thank you!

[rrthomas]

Unfortunately the only documentation currently for providers is the source. The enchant source does not have to be modified. Start at enchant-lsmod.c to see how the searching works.

I'd be very grateful of course for any notes you could provide on how to add a new provider (just write down what you learn), and best of luck. Do ask more questions and I'll do my best to help.

[rrthomas]

@norayr is this still something that might be interesting to you? I have recently changed the provider interface completely, and declared it "private", that is, internal to Enchant, but of course I'm still happy to receive contributions of new providers. So, I wondered whether there's still interest in that and whether I should keep this issue about improving documentation open.

[norayr]

hello,
so you mean now it's not possible to add a provider without having to commit to this project?

i was thinking back then, if i am able to use enchant to get the data, i could write some simple rudimentary algorithms to behave sort of in a more clever way than it is possible with hunspell/myspell.

i never did it, but i still think that one day i may come back to it. so it won't be possible? and i was thinking to do that for non english language, and i think it belongs to the separate repository, not this project.

[rrthomas]

Hi, thanks for responding!

To explain the current situation:

1. Spelling providers are dynamically-loaded plugins, so it's always possible to write one without committing to this project. (Also, the license allows providers for non-libre software, as before).
2. The change was that I have stopped promising that providers have a stable interface to the main library.

I should emphasise that we already have non-English providers in-tree: Voikko is mostly for Finnish, Hspell is only for Hebrew, and Zemberek is only for Turkish. I am always happy to have new providers, where it's easy to maintain them. So far, maintaining providers for 3rd-party libraries has not been a problem, either by myself (when the libraries are stable) or with help (when the libraries are developing, as with Nuspell).

On the other hand, if someone particularly wants to develop an out-of-tree provider, I'm happy to discuss it with them.

[norayr]

oh thank you! i don't have any plans for non open source providers. and thank you for mentioning these other providers, i can look at the code and learn from it.

and thank you for reminding about this. i'll try to free my mind and come back to this project.

[norayr]

i remembered what can be the other incentive to keep a separate out of tree project: the language. i may use some other language but make it loadable the same way.

[rrthomas]

That's a good point. As you can see, Enchant already uses C, C++, Objective C++ and Vala. I would certainly consider adding any language that compiles to C, or probably any language supported by GCC (e.g. Ada, D, FORTRAN, Go).

Another thing that might be important: I am considering a new major version of the Enchant API that fully uses GObject and GIR, so that any language that consumes GIR could be used directly.