GNU bug report logs -
#6967
flymake not cleaning after itself (kill-buffer)
Previous Next
To reply to this bug, email your comments to 6967 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#6967
; Package
emacs
.
(Wed, 01 Sep 2010 19:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
S Boucher <stbya <at> yahoo.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 01 Sep 2010 19:18:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
That's with emacs 23.2
flymake-kill-buffer-hook does not actually kill the flymake process. So, if flymake is used in conjunction with semantic, it gets problematic.
When semantic does background parsing, it may find-file/kill-buffer for files not already in memory. If semantic proceeds to kill-buffer while a flymake process is running, then a window pops up asking whether the buffer's process should be killed (because kill-buffer asks before killing processes).
It seems like flymake-kill-buffer-hook should kill the buffer, so that by the time semantic calls kill-buffer, there won't be a process to query about.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#6967
; Package
emacs
.
(Sun, 24 Oct 2010 17:11:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 6967 <at> debbugs.gnu.org (full text, mbox):
S Boucher <stbya <at> yahoo.com> writes:
> flymake-kill-buffer-hook does not actually kill the flymake process.
> So, if flymake is used in conjunction with semantic, it gets
> problematic.
>
> When semantic does background parsing, it may find-file/kill-buffer
> for files not already in memory. If semantic proceeds to kill-buffer
> while a flymake process is running, then a window pops up asking
> whether the buffer's process should be killed (because kill-buffer
> asks before killing processes).
>
> It seems like flymake-kill-buffer-hook should kill the buffer, so that
> by the time semantic calls kill-buffer, there won't be a process to
> query about.
It would be wrong for flymake-kill-buffer-hook to kill the buffer,
because there may be other functions on the hook that may need to
examine the buffer state.
The problem here seems to be that when Semantic visits files to parse
them, Flymake is enabled when it should not. I'm guessing you are using
flymake-find-file-hook, is that correct?
Maybe the solution is for Semantic to either avoid using
find-file[-noselect], or detect if Flymake is on and disable it for
files that are only being parsed temporarily. Eric, what do you think?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#6967
; Package
emacs
.
(Mon, 25 Oct 2010 11:12:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 6967 <at> debbugs.gnu.org (full text, mbox):
On 10/24/2010 01:14 PM, Chong Yidong wrote:
> S Boucher<stbya <at> yahoo.com> writes:
>
>> flymake-kill-buffer-hook does not actually kill the flymake process.
>> So, if flymake is used in conjunction with semantic, it gets
>> problematic.
>>
>> When semantic does background parsing, it may find-file/kill-buffer
>> for files not already in memory. If semantic proceeds to kill-buffer
>> while a flymake process is running, then a window pops up asking
>> whether the buffer's process should be killed (because kill-buffer
>> asks before killing processes).
>>
>> It seems like flymake-kill-buffer-hook should kill the buffer, so that
>> by the time semantic calls kill-buffer, there won't be a process to
>> query about.
>
> It would be wrong for flymake-kill-buffer-hook to kill the buffer,
> because there may be other functions on the hook that may need to
> examine the buffer state.
>
> The problem here seems to be that when Semantic visits files to parse
> them, Flymake is enabled when it should not. I'm guessing you are using
> flymake-find-file-hook, is that correct?
>
> Maybe the solution is for Semantic to either avoid using
> find-file[-noselect], or detect if Flymake is on and disable it for
> files that are only being parsed temporarily. Eric, what do you think?
Semantic uses semantic-find-file-noselect which clears out a list of
hooks and settings before calling find-file-noselect to avoid problems
like this.
Semantic needs a variant of find-file that puts a buffer into the
correct mode, which in turn runs the major-mode hook. It also needs to
run the mode-local hooks, but doesn't run miscellaneous other
interactive tool hooks.
I suppose Semantic could also have a pre-find-file hook that authors of
modes like flymake could install a temporary uninstall hook into, but
that seems kind of strange.
Eric
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#6967
; Package
emacs
.
(Mon, 25 Oct 2010 16:17:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 6967 <at> debbugs.gnu.org (full text, mbox):
> Semantic needs a variant of find-file that puts a buffer into the correct
> mode, which in turn runs the major-mode hook. It also needs to run the
> mode-local hooks, but doesn't run miscellaneous other interactive
> tool hooks.
IIUC Semantic visits those files "temporarily" (i.e. it will kill the
buffer afterwards, although probably not if the buffer already existed).
I think this need is not specific to Semantic, and so we should provide
this functionality in files.el. Maybe in a `with-found-file' macro.
Stefan
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#6967
; Package
emacs
.
(Mon, 25 Oct 2010 21:51:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 6967 <at> debbugs.gnu.org (full text, mbox):
> Semantic needs a variant of find-file that puts a buffer
> into the correct mode, which in turn runs the major-mode
> hook. It also needs to run the mode-local hooks, but
> doesn't run miscellaneous other interactive tool hooks.
>
> I suppose Semantic could also have a pre-find-file hook
> that authors of modes like flymake could install a temporary
> uninstall hook into, but that seems kind of strange.
A generic flag that indicates whether it is background find-file should be enough for flymake to decide not to run subprocesses, and for other modes to decide based on this flag.
Still, I think that on kill-buffer, flymake should just kill the process.
This bug report was last modified 14 years and 236 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.