emacs-devel
[Top][All Lists]
Advanced

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

Re: More problems with flyspell


From: Agustin Martin
Subject: Re: More problems with flyspell
Date: Mon, 9 Jan 2006 13:53:13 +0100
User-agent: Mutt/1.5.11

On Sun, Jan 08, 2006 at 09:47:58AM -0500, Richard M. Stallman wrote:
>     While we are with this, I have noticed that
>     flyspell-accept-buffer-local-defs is called from flyspell-large-region, 
> but
>     not from flyspell-small-region.
> 
> flyspell-small-region works by calling flyspell-word.  I thought that
> flyspell-word arranged to do flyspell-accept-buffer-local-defs, or
> the equivalent.  Doesn't it do that?

Not always with the optimization Piet mentioned, e.g. in next sequence, with
flyspell-region operating over a region that will call
flyspell-small-region

a) Load file and run flyspell-region on a small region. O.K.
   => Starting new Ispell process [francais0] ...
   => Spell Checking completed.
b) Notice you used the wrong dict, ispell-change-dictionary to the new one
   => Loading cl-macs...done
   => Ispell process killed
   => Local Ispell dictionary set to francais
c) Run again flyspell-region on the same region
   => if: Buffer french-LIZEZMOI has no process

> However, if calling flyspell-accept-buffer-local-defs twice does no
> harm, it would be fine to move that call into flyspell-region.

However, you are right, (flyspell-word) is the key here and if instead of
(c) you run flyspell-word over a word the same error appears. I think we can
handle this from ispell.el as part of the
ispell-change-dictionary+double-call problem making sure
flyspell-last-buffer is nil'ed on dict change if flyspell is loaded. this
way first call to flyspell-word would re-run
flyspell-accept-buffer-local-defs and skip that for further calls from the
same buffer. No need to add an explicit call in flyspell-small-region or
flyspell-region.

This might also fix the original problem Piet described, but in a different
way (compatible with the current fix, no need for changes there).

-- 
Agustin




reply via email to

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