GNU bug report logs -
#6143
24.0.50; don't ispell-kill-ispell over and over
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Sun, 9 May 2010 01:22:01 UTC
Severity: minor
Found in version 24.0.50
Done: jidanni <at> jidanni.org
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Sun, May 09, 2010 at 09:21:45AM +0800, jidanni <at> jidanni.org wrote:
> Every time I even do a
> S runs the command w3m-search, which is an interactive compiled Lisp
> function in `w3m-search.el'.
>
> I see a
> Starting new Ispell process [american] ...
>
> Looking in *Messages*
> Note: file is write protected
> Ispell process killed
> Starting new Ispell process [american] ...
> Mark set
> Mark saved where search started [5 times]
> Ispell process killed
> Starting new Ispell process [american] ...
> Ispell process killed
> Making completion list...
> Scanning for dabbrevs...100%
> Starting new Ispell process [american] ...
The part of your dotfiles that triggers this is in .emacs-w3m
(add-hook
'minibuffer-setup-hook
(lambda ()
(if(string-match "TEXT: \\| search: " (minibuffer-prompt))
(flyspell-mode 1))))
and is related to my changes in bzr:#100056 killing ispell if buffer where
ispell process was generated is killed. (partially related to bzr:#100055)
The reason for that changes is that when emacs visits a file in a removable
device and an ispell process is launched in that file, ispell process sets
the dir in the removable device as default dir, so if one switch to other
buffer outside the removable device and original buffer is killed, unless
ispell process is restarted (personal dictionary, localwords, different
language) or just killed, removable device stays bound and cannot be
unmounted.
This is the reason for ispell process being killed when buffer where it was
created is killed. Since you create a buffer (the minibuffer) and a new
ispell process for it, this is the behavior you get. Note that this will
not happen if in the main buffer you already have an ispell process started
for the same language you will use in the minibuffer.
Will think about it, but I do not see an easy workaround to take care of
both things reliably.
Cheers,
--
Agustin
This bug report was last modified 14 years and 212 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.