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

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

bug#6143: 24.0.50; don't ispell-kill-ispell over and over


From: Agustin Martin
Subject: bug#6143: 24.0.50; don't ispell-kill-ispell over and over
Date: Wed, 12 May 2010 12:26:07 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, May 11, 2010 at 05:18:26PM +0200, Agustin Martin wrote:
> I am still trying to think about something cleaner, or at least about a
> reasonable workaround.

I have been thinking about this, and about a fix that is XEmacs compatible.
Although current ispell.el and flyspell.el cannot be used out of the box in
XEmacs, I am using for Debian one of the versions before the CVS->bzr
migration heavily patched to also work for XEmacs and keep a consistent
spellchecking interface across different Emacs flavors. As a matter of fact
it is even patched to work with emacs 21.3, but this is something I do not
want to maintain any longer.

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
started faked in this specific case, so process is not killed when buffer is
killed. Since process is asigned to $HOME no problems are expected when this
is done from a buffer in a removable device creating a minibuffer. However,
usual ispell behavior will not be fully honoured here, but this is a
side use.

Something like

    (if (window-minibuffer-p)
        (setq ispell-process-directory (expand-file-name "~/")
              ispell-process-buffer-name 
                        " *Minibuffer-1-has-spellcheck-enabled")
      (setq ispell-process-directory default-directory
            ispell-process-buffer-name (buffer-name)))

The second approach requires a clean and portable way of knowing the
parent buffer for the relevant minibuffer. In this case, just naming
ispell-process-buffer-name as parent buffer name may work. 

I currently do not see a good way to do the second, so first approach should
be a reasonable compromise. I will test a bit more and commit if no further
problems appear.

-- 
Agustin





reply via email to

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