bug#7781: hunspell and latex-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Peter Münster <pmlists@free.fr>
> Date: Tue, 29 Apr 2014 14:48:43 +0200
> Cc: 7781@debbugs.gnu.org
> 
> I've just tried unpatched hunspell: no problem with TeX-mode.
> It's the patch on sf.net that breaks the TeX-mode, the character
> position is always 0:
> https://sourceforge.net/p/hunspell/patches/57/#d425

That's what I thought.  If I invoke Hunspell like ispell.el does for a
LaTeX buffer, i.e.

  hunspell -a -d en_US -i UTF-8

and then type "^bla RET" into Hunspell, I get this as output:

  & bla 15 1: alb, bl, la, bola, blah, blab, lab, baa, ala, bra, boa, Ila, Ala, Ola, Ula

As you see, I get "15 1".  If you get 0 instead of 1, then that's the
cause of the problem, because the part of your debug output marked
below:

  ispell-process-line: Ispell misalignment error:
    [Word from ispell pipe]: [bla], actual (point,line,column): (41,2,16)
                                                                 ^^^^^^^
clearly shows that ispell.el is confused about where the word "bla"
begins in the buffer; the correct data is 42,3,0.  Also note that just
before reading Hunspell's output, ispell.el correctly identified both
the word and its location:

  ispell-region: string pos (42->45), eol: 45, [in-comment]: [nil], [add-comment]: [nil], [string]: [^bla
  ]

> I'll build hunspell with Eli's patch now.

I think that will solve the problem.

(I have no idea why visiting the same file in Text mode avoids the
problem.  The only difference is that in Text mode, ispell.el does not
skip the first 2 lines, but instead submits them to Hunspell.  Why
this makes the difference, I don't know, but probably the lone "^bla"
somehow triggers the bug in the patch you installed, whatever that bug
is.)