emacs-bug-tracker
[Top][All Lists]
Advanced

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

[Emacs-bug-tracker] bug#6143: closed (24.0.50; don't ispell-kill-ispell


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#6143: closed (24.0.50; don't ispell-kill-ispell over and over)
Date: Thu, 13 May 2010 11:06:01 +0000

Your message dated Thu, 13 May 2010 13:05:07 +0200
with message-id <address@hidden>
and subject line Re: bug#6143: 24.0.50; don't ispell-kill-ispell over and over
has caused the GNU bug report #6143,
regarding 24.0.50; don't ispell-kill-ispell over and over
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
6143: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6143
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.0.50; don't ispell-kill-ispell over and over Date: Sun, 09 May 2010 09:21:45 +0800
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] ...

Why couldn't things be left as they were? I.e., just let it live.
See http://jidanni.org/comp/configuration/ for my dotfiles if curious.




--- End Message ---
--- Begin Message --- Subject: Re: bug#6143: 24.0.50; don't ispell-kill-ispell over and over Date: Thu, 13 May 2010 13:05:07 +0200 User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, May 12, 2010 at 10:28:26AM -0400, Stefan Monnier wrote:
> > I am thinking about two possible approaches, one is a compromise, minibuffer
> > is somewhat special, so ispell process directory could be set to $HOME only
> > when spellchecking minibuffer, and name of buffer where ispell process is
> 
> How about associating ispell processes with default-directories rather
> than just with buffers?  I.e. share ispell processes between buffers
> that share default-directory.  

That is current behavior unless buffers use different languages for
spellchecking or have a set of localwords defined (which may be different
for different buffers, needing process restart).

> And use $HOME whenever possible
> (i.e. when we can determine that there's no local dictionary in
> default-directory).

Doing this without the kill-ispell-on-kill-buffer machinery may still leave
some corner cases. 

Noticed that this dual personal dictionary behavior seems to be an ispell
only feature. If properly handling this is causing more harm than good, it
may even be dropped by forcing ispell-process-directory to always be $HOME.  

Anyway, I have commited a possible fix for jidanni's problem, making
parent-dir 'owner' of ispell process in a minibuffer'. Hope this fixes the
problem.

Closing bug report,

-- 
Agustin


--- End Message ---

reply via email to

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