emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flyspell-region bug


From: Agustin Martin
Subject: Re: Flyspell-region bug
Date: Wed, 1 Mar 2006 00:41:18 +0100
User-agent: Mutt/1.5.9i

On Mon, Feb 27, 2006 at 11:50:13AM +0100, Slawomir Nowaczyk wrote:
> On Fri, 24 Feb 2006 12:44:41 +0100
> Agustin Martin <address@hidden> wrote:
> 
> #> > Nevertheless, I find it somewhat disturbing that flyspell *did not*
> #> > complain but silently decided to ignore the misspelling ispell
> #> > reported...
> #> 
> #> Note that flyspell found it, but with the wrong case.
> 
> Well, it didn't really find it... it found the word but decided it is
> *not* a misspelling, despite the fact that ispell said it is.

Hi, Slawomir

The process is as follows, from

Washington washington

ispell listed "washington" as misspelling, flyspell.el then looked for
"washington", but since search was case-insensitive, found "Washington"
first, which is actually not a misspelling, and validated it, so flyspell
thought "washington" is correct and tried next misspelling (Was really
validated by size, but validating by flyspell-word success would have
also succeeded). An alternative would be validating by string=, but if
search is forced to be case-sensitive I think is not needed.

> I am far from flyspell expert, 

Same for me,

> #> > Wouldn't it be better to at least show a message when this happens?
> #> 
> #> In this case no message would have been issued since misspelling was
> #> (wrongly) found, so words-not-found should be finally empty.
> 
> Well, I think I would like a message in this case as well: namely when
> ispell reports a misspelling, the word is found, but flyspell-word
> (the one in line 1387 of flyspell.el) doesn't mark it.
> 
> *To me*, it seems to indicate a likely problem. In what situation
> would something like this not be a bug?

There are some places where this can happen,

flyspell-large-region passes buffer to ispell as plain text, because
misspellings search in that buffer will be done with normal emacs search
functions as plain text. That makes most sgml or LaTeX tags be marked as
misspellings by ispell, but ignored by flyspell that knows that the buffer
is TeX/sgml. {ispell,flyspell}.el sgml deformatter is better than ispell
one, so telling ispell that file is sgml is not enough. Same for TeX, with
the added problem that things will be broken for 8bit chars (ispell would
expect things like \'a here). I think I mailed the list about this last,
but cannot find now the reference.

Another example where that can happen is with session localwords,
which are not passed to ispell in (flyspell-large-region) function, but
are recognized as correct by (flyspell-word). I have thinking about handling
them through flyspell-process-localwords, but I still have some things
unclear.

This kind of things can also appear when there is a boundary-chars mismatch
between what ispell.el considers valid and what ispell considers valid,
sometimes in obscure and confusing ways from ~/.emacs user entries.
Depending on where are more chars accepted, words-not-found will not be
nil of flyspell-word will be tried on a correct word.

I think the best for now is fix (flyspell-external-point-words) as you
suggested, making sure search is case-sensitive, as well as
(flyspell-process-localwords) which suffers from the same problem
(patch already sent). Messages might otherwise become too noisy for no good
reason.

Note that all of flyspell-large-region is a *big* hack to make spellchecking
of large regions minimally efficient, and this has some drawbacks (of
course, if we can fix them, better)

-- 
Agustin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]