On Mon, Dec 19, 2005 at 02:28:17AM +0100, Agustin Martin wrote:
> On Mon, Dec 19, 2005 at 01:41:15AM +0100, Agustin Martin wrote:
> > On Fri, Dec 16, 2005 at 08:03:25PM -0500, Richard M. Stallman wrote:
> > > I think this fix is a cleaner one.  Does it work right?
> > I will try testing this in a current emacs when I can. I still do not
> > understand where and why is the jump produced in that file, but as mentioned
> > above seems related to words tagged as not found because contain chars not
> > in casechars or boundary-chars, but actually found in the search loop thus
> > moving point.
> 
> Tested a bit more, and indeed related to boundary chars mismatch. I am
> considering a better approach for this kind of mismatches, but is still
> untested.

Testing things in emacs-snapshot, so we get real up-to-date results.

The matter here is if search for next misspelling should start where
searches involving last misspell ended or only where last validated match
was. I am strongly in favour of the second option and that is what my patch
proposed. The reason for this is that boundary-char mismatches between
ispell and ispell.el are a potential source for problems that are not easy
to debug. Having updated ispell-dictionary-alist entries is not enough,
because this is still very subjected to user settings in the ~/.emacs file
or to changes in the ispell aff file (this last should not be a problem for
aspell, where ispell.el detects boundary-chars, but users settings might
still be).

Since this is hard to debug for a normal user I am strongly in favour of
the conservative option, moving search start only after a validated match.

I was testing previous flyspell.el version with your last non-installed patch
in a test-system where dot is declared as boundary char in ispell francais
dict but not in ispell.el (this is fixed in current ispell.el, but some
~/.emacs might put it wrong) with the contents

francais.aff
anothermisspell
francais.aff
francais.aff
francais.aff

flyspell do not think francais.aff is a word, so it is not validated and is
re-searched and finally marked as not found, but point is then at the last
francais.aff appearance, so next misspelling, "anothermisspell" is also not
found, as well as any other misspelling in the middle. Bad forward unsync.

There is something else in the validation code that can be improved, based
on Piet van Oostrum suggestion in the old "flyspell bug" thread, validate
if misspelling length is higher than length of what flyspell considers a
word. In the above example, "francais.aff" would be the misspelling, but
considering where point is, flyspell would say that current word is "aff",
and since length("francais.aff") > length("aff") match would be validated
and the above example work even in a per-search point move.

Unfortunately this might not work with more ellaborated mismatches, so I
think we should combine both things, validating also as above and be
safer starting searches from last validated match.

I am attaching a more ellaborated patch for consideration

-- 
Agustin