This plugin does work on Windows 10

[mardukbp]

I installed MSYS2, opened MSYS2 MSYS and then:

pacman -Syu
pacman -S aspell-devel aspell6-en

Currently, aspell-devel corresponds to version 0.68, which adds support for Markdown.

In Windows I added C:\msys64\usr\bin to the user %PATH% and wrote a launcher script for micro:

@ echo off
set MICRO_TRUECOLOR=1
set LANG=en_US.UTF-8
micro.exe %1

Setting the %LANG% environment variable is crucial for the correct functioning of aspell. It took me hours to learn this.

It is also important that C:\msys64\usr\bin is searched before any other location where sh.exe is available. E.g. the GitBash installation directory. sh is the program executed by micro to launch external commands.

Thank you so much for writing this plugin!

[priner]

Thank you for testing it out!

I don't have an easy access to a Windows machine which made it kinda hard for me to test the plugin on it, so your help/findings are greatly appreciated. I was not aware of MSYS2. Seems that's the most reasonable way of installing Aspell on windows now. I only tested with the outdated unmaintained native port.

What exactly is not working with LANG unset? Are non-ASCII characters turned into question marks or something worse? I think this is a problem of Aspell assuming some default encoding which is not utf-8 (probably just ASCII). I will try to pass the actual encoding of a file in micro to Aspell, which would also hopefully make this plugin work for non-utf-8 files.

The issue with sh is already fixed on master (this plugin doesn't invoke it anymore), I just haven't released a new version yet, since I wanted to make it work on Windows first. If you want to try it out you can directly clone this repo to ~/.config/micro/plug/aspell.

[priner]

The last commit should have fixed the problem with LANG environment variable not set. Could you test it out? If it works on Windows with no workarounds required I will update the help file and release it.

[mardukbp]

What exactly is not working with LANG unset? Are non-ASCII characters turned into question marks or something worse?

Non-ASCII chars are not shown and in addition unexpected behavior happens. For example, I have a Markdown file which contains code snippets like

`java -cp some.jar SomeClass`

When LANG is not set, somehow the above snippet is executed by Bash.

Passing --encoding=utf-8 does nothing. And there is no utf-8.cset in /usr/lib/aspell. Moreover, I found the following in aspell.texi:

If Aspell is compiled with a version of the curses library that support wide characters then Aspell can also check UTF-8 text. Furthermore, the document will be displayed in the encoding defined by the current locale. This encoding does not necessarily have to be the same encoding that the document is in. This means that is is possible to check an 8-bit encoding such as ISO-8859-1 on an UTF-8 terminal. To do so simply set the @option{encoding} option to @samp{iso-8859-1}.

Therefore, I believe that for UTF-8 one has to set the $LANG environment variable. For other encodings one can use the --encoding flag.

You can try this by issuing export LANG= in a Bash session.

The issue with sh is already fixed on master (this plugin doesn't invoke it anymore)

I do not think so. shell.JobSpawn calls sh.

[priner]

I finally get on to test it on Windows myself, and it did seem to work just fine with the fixes, so I released a new version (it requires micro>=2.0.7). You can run plugin update to get it.

I do not think so. shell.JobSpawn calls sh.

Only JobStart calls it, JobSpawn does call the program you want directly. This plugin used to use JobStart, but now uses JobSpawn, which should fix the problem with code in buffer being executed, as now the text doesn't even go through the shell.

And there is no utf-8.cset in /usr/lib/aspell.

The .cset files seem to define a mapping between byte values and Unicode codepoints, which you kind of get for free with utf-8, no need for .cset.

[mardukbp]

Only JobStart calls it, JobSpawn does call the program you want directly.

Oops! My bad. Sorry.

it did seem to work just fine with the fixes

Yep. Thank you so much for this plugin!

[mardukbp]

@priner With this version of the plugin spellchecking is slower, to the point that it is uncomfortable. I am editing a 300-line Markdown file.