跳至主要内容

Emacs 26.2 windows Hunspell setup

 Hunspell failed with default setup

With my shining new emacs26.2 setup, I am happy until trying to `M-$’ on a word.

I got following error message, it used to be work by just set ispell program to hunspell.

Starting new Ispell process hunspell with default dictionary...
split-string: Wrong type argument: stringp, nil

After some check in my customization setting. nothing found.

install a copy of hunspell dictionary

At first I think it was caused by no hunspell dictionary. I downloaded enUS and enCA hunspell dictionary from wordlist.sf.net project.

After put the .aff and .dic files into C:directory

I’ve also made a symbolic link from enUS ones by running the `mklink’ tool:

mklink default.aff en_US.aff
mklink default.dic en_US.dic

Err… hunspell does not work, still.

Time to read code

Dig into ispell.el I suprisingly find there’re lots of hunspell specific logic. Originally I was thinking hunspell support involves no elisp work.

Acturally ispell did many work to determind dictionary list for hunspell. And it seemed that my recently installed, shining new, chocolatey managed hunspell.portable is causing problem.

with azwinport, the hunspell command will determind installed dictionary correctly as shown bellow:

# bin\hunspell.exe -D
SEARCH PATH:
.;;C:\Hunspell\;c:\opt\nobody\.openoffice.org\3\user\wordbook;C:\Users\nobody\Downloads\hunspell-1.3.2-3-w32-bin\bin\..\share\hunspell;C:\Program files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program files\OpenOffice.org 2.0\share\dict\ooo\
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
C:\Hunspell\default
C:\Hunspell\en_CA
C:\Hunspell\en_US
C:\Users\nobody\Downloads\hunspell-1.3.2-3-w32-bin\bin\..\share\hunspell\default
C:\Users\nobody\Downloads\hunspell-1.3.2-3-w32-bin\bin\..\share\hunspell\en_GB
C:\Users\nobody\Downloads\hunspell-1.3.2-3-w32-bin\bin\..\share\hunspell\en_US
LOADED DICTIONARY:
C:\Hunspell\\default.aff
C:\Hunspell\\default.dic
Hunspell 1.3.2

With chocolatey managed hunspell, nothing but the default loaded one is reported.

# hunspell.exe -D -a .viminfo
SEARCH PATH:
.;;C:\Hunspell\;%USERPROFILE%\Application Data\OpenOffice.org 2\user\wordbook;C:\Program files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program files\OpenOffice.org 2.0\share\dict\ooo\
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
LOADED DICTIONARY:
C:\Hunspell\\default.aff
C:\Hunspell\\default.dic
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)

fix it by provide the hunspell dict paths alist

finally I managed to run the hunspell spellchecker by add following lisp code into my .emacs.

(setq-default ispell-hunspell-dict-paths-alist
          '(
        ("default" "C:\\Hunspell\\default.aff")
        ("en_US" "C:\\Hunspell\\en_US.aff")
        ("en_CA" "C:\\Hunspell\\en_CA.aff")
        ))

评论

此博客中的热门博文

Eglot and before/after-save-hook and use-package

In Emacs, when you try to automate some actions during every save action, you will surely get to the before-save-hook and the after-save-hook. Simply adding something like gofmt-before-save to before-save-hook will save you tons of time to do the go-fmt. And then, I meet eglot, and gopls will also save me tons of time doing googling and api documentation navigation. But eglot-ensure is not very friendly to the good old ways of how after-save-hooks were designed to work. It makes the before/after-save-hook a buffer local variable and it does not inherit the variable's global value. So, to make before/after-save-hook work again, experts start to adding hooks to major mode specific hooks like this: emacs.md - Go (opensource.google) """ ;; Optional: install eglot-format-buffer as a save hook. ;; The depth of -10 places this before eglot's willSave notification, ;; so that that notification reports the actual contents that will be saved. (defu...

XEmacs 21.5 beta 35 "kohlrabi" has been released.

If you are an old XEmacs user, you may feel happy to see this from https://www.xemacs.org/.    After ten years, XEmacs released a new version 21.5. So there's still many people cares about XEmacs. The XEmacs' source repo have been moved from altassian Bitbucket to https://heptapod.net/. As Bitbucket have been dropped Mercurial support many years ago.