feat: native windows provider

[Kneemund]

This PR adds a provider for the native spellchecking added in Windows 8. Deleting words from the session (optionally) requires at least Windows 10. Closes #52.

I spent quite some time fighting the build system. The squashed changes seem idiomatic to me. I'd appreciate some feedback on that ;)

The CI on Windows is currently failing due to a bug in the CLI. This is fixed by the PR #439.

Licensing

I'm by no means an expert at licenses, but here is the way that I see things. This should definitely be double-checked by someone other than me.

The new provider uses the bcp47 module from gnulib to convert between BCP47 language tags (which Windows uses) and XPG/POSIX language tags (which all other providers use). This module is licensed under LGPLv3+. The source code of the provider is licensed under MIT. That makes the whole provider derived work and thus also LGPLv3+.

I think that enchant itself stays LGPLv2+, since the provider is loaded dynamically and not at all a core component.

In the process, I had to loosen the LGPL restriction of gnulib_tool (see 4f9ac6b) so that it can include any LGPL licensed modules, not just LGPLv2 licensed ones. That means that we have to be more careful about the modules we use in the future. I don't know if we can somehow limit this to just the new provider. We would probably need an entirely separate build step.

TODOs

• Use a better name and description for the provider. win8 sounds like it only works on Windows 8. Suggestions would be very welcome.

[rrthomas]

This is amazing to have, many thanks! I must apologise that you've caught me at a moment where I'm unable to be likely to look at it in a matter of days, and possibly not weeks, so do ping me if you don't hear for a while, but rest assured it is something I really want to land.

Thanks in particular for taking care with the build system and checking the situation with the tests and CI.

[rrthomas]

I've had a quick look at this. I agree the name should be changed, because it should reflect the interface, not the version of Windows. It's unfortunate that the type is ISpellChecker, which sounds too much like the venerable "ispell". It's similarly unfortunate that the header file is just called spellcheck.h.

How about winspell, by analogy with "applespell", which has similar internal problems of genericity?

Please can you squash all of the commits that deal with the provider itself into one?

Please can you also remove the commits that have nothing to do with the provider? They can be the subject of other PRs. (Although for example, I don't think adding APPLESPELL_LIBS makes sense, as there is no such variable, so that commit can be discarded.)

[rrthomas]

Thanks for the update, and again apologies for my slowness with this.

[Kneemund]

No problem, thank you for the feedback. I will squash these changes soon, I'll also create some PRs with the other changes.

[Kneemund]

Alright, I think this PR is ready for review once again. I've removed all the unrelated changes.

Are you sure that all of these commits should be squashed? Wouldn't it make more sense to squash them when merging the PR (using the GitHub UI)?

[rrthomas]

Are you sure that all of these commits should be squashed? Wouldn't it make more sense to squash them when merging the PR (using the GitHub UI)?

Maybe not all commits, but any commits that fix code in earlier commits, if you've not done that already. So specifically I would not expect to see any "fix" commits that fix code introduced in this PR.

[Kneemund]

Alright, I think the commits are somewhat reasonable now.

[Kneemund]

@rrthomas Do you have time (and motivation) to take another look? It's fine if you don't, I just saw this PR on my GitHub home page and was reminded.

[rrthomas]

@rrthomas Do you have time (and motivation) to take another look? It's fine if you don't, I just saw this PR on my GitHub home page and was reminded.

No time at present, but I'm still motivated, and it's on my list! Sorry for the delay.

[rrthomas]

I've finally found some time to work on non-trivial Enchant issues, and after a while working on easier things, came to this!

Thanks very much again for working on this, @Kneemund.

I would be very grateful if you confirm it seems to be working OK for you in its current form (I have rebased on main and squashed the commits of this PR).

There's one small but annoying thing I don't like: I don't want to change bootstrap.conf to --lgpl[=3] just for the sake of one provider. Since each provider is a separate library, I don't believe that building the WinSpell provider forces libenchant to be under the LGPLv3.

But more importantly, I want to keep the check that other modules are not being mistakenly linked against LGPLv3-only gnulib modules.

I can't think of an easier way to fix this than to have a special gnulib installation just for the WinSpell provider. Can you? Don't worry, I don't expect you to implement that; I've already got another project with multiple libgnu's, so I can copy that.

[rrthomas]

The author of the bcp47 module, Bruno Haible, bless him, has relicensed it under LGPLv2.1+, so that problem is gone.

[Kneemund]

Thanks for reviewing and working on this! I just compiled and tested the latest version on my Windows installation and it works fine.

enchant-lsmod-2.exe -list-dicts

> enchant-lsmod-2.exe -list-dicts
de_AT (winspell)
de_CH (winspell)
de_DE (winspell)
de_LI (winspell)
de_LU (winspell)
en_CA (winspell)
en_LR (winspell)
en_PH (winspell)
en_US (winspell)

enchant-2.exe -l -L --dictionary=en_US README.md

> enchant-2.exe -l -L --dictionary=en_US README.md
1 libenchant
4 rrthomas
4 github
5 github
5 rrthomas
7 libenchant
22 Hunspell
22 Myspell
23 Nuspell
24 Aspell
25 Hspell
26 Voikko
28 WinSpell
29 Zemberek
31 Vala
35 doxygen
41 tarball

[rrthomas]

Thanks for confirming. I'll make a release.