Re: (long) Ispell misalignment
The following message is a courtesy copy of an article
that has been posted to comp.emacs.xemacs as well.
On Mon, 8 Dec 2003 at 15:10:30 -0800, Itay Furman <itayf(a)fhcrc.org>
wrote on comp.emacs.xemacs:
I hope that this is the right place for this post.
This newsgroup is good for getting in touch with people who have already
solved a problem you are now facing. For things that need developer
attention, mail to xemacs-beta(a)xemacs.org is better. I am sending my
response to that newsgroup, so followups should go there as well. I'll
let you decide if you want to keep the newsgroup in the loop or not.
Also, for future reference, M-x report-emacs-bug will present you with a
mail buffer containing information about your XEmacs. All you have to
do is fill in the details of your problem and send it in.
ispell-buffer, when run on a latex source file stops at the
following
line, at the word 'SNP':
\subsection{Comparison with \textbf{STR} and \textbf{SNP} based linkage}
with the following message:
"Ispell misalignment: word 'STR' point 10795; probably incompatible
versions"
If you look at the ispell.el file (M-x find-library ispell), you'll see
that it identifies a few scenarios that can lead to this error message.
Right above the line that generates the error, it says:
;; This occurs due to filter pipe problems
although what that has to do with "incompatible versions" is a mystery
to me. A few lines higher up it says:
;; Alignment cannot be tracked and this error will occur when
;; `query-replace' makes multiple corrections on the starting line.
At the very top of the file, under BUGS, it says:
;; Multi-byte characters if not defined by current dictionary may result in the
;; evil "misalignment error" in some versions of MULE emacs.
and:
;; Recursive edits (?C-r or ?R) inside a keyboard text replacement check (?r)
;; can cause misalignment errors.
So I ran aspell on the file outside xemacs and it went through
without any problem.
The problem isn't that aspell can't process the file. The problem is
that aspell's idea of where point is in the file is different from
XEmacs' idea of where point is in the file. Why they have different
ideas is the question here.
Still in the new directory I played with ispell-region and found
that I can reproduce the problem with only two lines from the
original file (where they appear in tandem)
coppied into separate files, each.
line1.tex:
\subsection{Comparison with \textbf{STR} and \textbf{SNP} based linkage}
line2.tex:
\label{sec:sim:cmp}
For example, I reprodcued the error like this:
Restart xemacs.
C-x f line2.tex RET (load 2nd line)
M-x ispell-buffer RET (OK)
C-x f line1.tex RET (load 1st line)
M-x ispell-buffer RET (OK)
C-x b line2.tex RET (change to 2nd line again)
M-x ispell-buffer RET (**ERROR**)
So the error appears when checking the 2nd line, but only *after*
the first line is checked.
This is good! Reproducible test cases are a debugger's dream. I see
it, too. When I run with edebug, I see that, on a "good" run,
ispell-process-line communicates with the subprocess, after which
ispell-filter is nil. On a "bad" run, after ispell-process-line
communicates with the subprocess, ispell-filter contains a list of
strings *from spellchecking SNP in line1.tex*! That's why it is getting
confused. So why is ispell-filter wrong?
I instrumented ispell-filter for debugging, and sure enough, it gets the
return string for SNP *after* it was requested to check "\label{".
Weirdly enough, it then gets the return string for STR! Somehow,
communication with the subprocess has gone badly awry.
--
Jerry James
http://www.ittc.ku.edu/~james/