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

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

bug#6143: 6143 ispell not fixed


From: Agustin Martin
Subject: bug#6143: 6143 ispell not fixed
Date: Thu, 29 Jul 2010 13:41:21 +0200

2010/7/27 Dan Nicolaescu <dann@gnu.org>:
> Agustin Martin <agustin.martin@hispalinux.es> writes:
>
>> On Sat, Jul 24, 2010 at 01:35:06AM -0400, Dan Nicolaescu wrote:
>>>
>>> You can get the "Ispell process killed" message by doing:
>>>
>>> $ echo $LANG
>>> C
>>> $ emacs -Q
>>> M-: (add-hook 'text-mode-hook       'flyspell-mode) RET
>>>
>>> C-x C-f A_FILE_UNDER_VERSION_CONTROL_FOR_EXAMPLE_MANAGED_BY_GIT
>>> type something
>>> C-x v v
>>> type something in the log-edit buffer.
>>> C-c C-c
>>>
>>> now look at the *Messages* buffer and see the "Ispell process killed"
>>
>> Strange, I get a different result (although also with an error),
>>
>> $ LANG=C LC_ALL=C emacs-snapshot -Q &
>> M-: (add-hook 'text-mode-hook       'flyspell-mode) RET
>> C-x C-f A_FILE_UNDER_GIT_VERSION_CONTROL (kkk.txt)
>> type something
>> C-x v v
>> type something in the log-edit buffer.
>>
>>   Error during redisplay: (error No match 4 in highlight (4 
>> font-lock-warning-face))
>>
>> C-c C-c
>>
>>   Buffer kkk.txt modified; save it? (y or n)
>>   Error during redisplay: (error No match 4 in highlight (4 
>> font-lock-warning-face))
>>
>> But no ispell process restart.
>
> When I ispell-kill-ispell is invoked the backtrace looks like this:
>
>  ispell-kill-ispell(t)
>  (if (equal ispell-process-buffer-name (buffer-name)) (ispell-kill-ispell t))
>  (lambda nil (if (equal ispell-process-buffer-name ...) (ispell-kill-ispell 
> t)))()
>  kill-buffer(#<buffer *VC-log*>)
>  vc-finish-logentry()
>  call-interactively(vc-finish-logentry)
>  log-edit-done()
>  call-interactively(log-edit-done nil nil)
>
>
> So this is caused by:
>
> (add-hook 'kill-buffer-hook
>            '(lambda ()
>                 (if (equal ispell-process-buffer-name (buffer-name))
>                      (ispell-kill-ispell t))))
>
>
> ispell-process-buffer-name is "*VC-log*"

Thanks for debugging, Dan

I guess your original A_FILE_UNDER_GIT_VERSION_CONTROL file is not a
text-mode file. If so, this is the currently expected behavior, do not
leave unused ispell processes behind.  So, no ispell process is
started for initial file, and only when you start the text mode buffer
"*VC-log*", an ispell process is started. Since there was no previous
process "owned" by a previous buffer, this is killed on buffer kill.

Note that I was playing with a text file, so an ispell process is
started for it and, since it does not contain neither localwords nor
an explicit language different from default, same process is used for
"*VC-log*" buffer and is not killed on "*VC-log*" kill since it was
initiated from original buffer. That is the difference I find. What
happened before for me is that I probably did not use the file as
kkk.txt, but as plain kkk.

This being too noisy or not is open for discussion, others may argue
that leaving unused ispell processes behind is also a bug.  I
personally do not find this noisy enough. Opinions welcome.

If this is considered too noisy and leaving unused ispell processes
behind not a problem I think the way to go is to always use "~/" as
ispell process directory, so problem with removable media that used
the kill-on-kill gets also fixed. Better if there is a not too
complicated way of having an exception when Ispell is the
spellchecking engine and original directory contains an Ispell
directory dictionary for given language. This way if using Ispell,
current directory is used as ispell-default-directory only if contains
appropriate directory personal dictionary and process is killed on
buffer kill only if so (IIRC someone already proposed this, but I do
not find original mail).  Otherwise we lose support for this Ispell
funcionality. Have to think a bit about this.

PS: I have been lately with limited time and connectivity. Do not
expect something quickly.

-- 
Agustin





reply via email to

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