Eli Zaretskii writes: >> From: Joseph Mingrone >> Date: Fri, 21 Oct 2016 02:04:58 -0300 >> This still seems to be a problem with hunspell version 1.3.3. >> The problem can be reproduced by spell checking a file with this one line. >> alsdk ✅ sdfkjdsf sldksdfkjsfd >> During spell checking, the process list shows: >> ispell run -- -- /usr/local/bin/hunspell -a -d en_CA -i UTF-8 >> The error Emacs (version 25.1.1) reports is: >> ispell-process-line: Ispell misalignment: word ‘sdfkjdsf’ point 11; probably incompatible versions > Did Hunspell ever fix the problem whereby it reported byte offsets of > the misspelled words, as opposed to character offsets? If not, that > is your problem, and Hunspell should finally get its act together. > To see whether this is the problem, invoke Hunspell like this: > /usr/local/bin/hunspell -a -d en_CA -i UTF-8 < test.txt > and see what Hunspell emits. It should emit something like this (the > below is taken from my system, and I don't have the en_CA dictionary, > so your output might be slightly different): > @(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.2) > & alsdk 3 0: Alaska, elastic, Alston > & sdfkjdsf 2 8: artefact's, postfix > & sldksdfkjsfd 2 17: justification, staphylococcus > The second number after each misspelled word is the offset of that > word's beginning, measured in characters, from the start of the line. > Hunspell used to report this in bytes instead of characters; if it > still does, you will have to patch it to fix that bug. AFAIR, the > Hunspell issue tracker includes several patches for this bug. Or > maybe the latest Hunspell 1.4.1 already fixes this, in which case > please upgrade. It's still a problem with hunspell. % echo "é startingCharTwo" | hunspell -a -d en_CA -i UTF-8 @(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.3) & é 15 0: e, s, i, a, n, r, t, o, l, c, d, u, g, m, p & startingCharTwo 1 3: nonparticipating https://github.com/hunspell/hunspell/issues/418