GNU bug report logs - #6967
flymake not cleaning after itself (kill-buffer)

Previous Next

Package: emacs;

Reported by: S Boucher <stbya <at> yahoo.com>

Date: Wed, 1 Sep 2010 19:18:02 UTC

Severity: normal

To reply to this bug, email your comments to 6967 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: S Boucher <stbya <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: flymake not cleaning after itself (kill-buffer)
Date: Wed, 1 Sep 2010 12:19:02 -0700 (PDT)
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):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: S Boucher <stbya <at> yahoo.com>
Cc: Eric Ludlam <zappo <at> gnu.org>, 6967 <at> debbugs.gnu.org
Subject: Re: bug#6967: flymake not cleaning after itself (kill-buffer)
Date: Sun, 24 Oct 2010 13:14:38 -0400
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):

From: "Eric M. Ludlam" <eric <at> siege-engine.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: S Boucher <stbya <at> yahoo.com>, Eric Ludlam <zappo <at> gnu.org>,
	6967 <at> debbugs.gnu.org
Subject: Re: bug#6967: flymake not cleaning after itself (kill-buffer)
Date: Mon, 25 Oct 2010 07:15:47 -0400
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):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Eric M. Ludlam" <eric <at> siege-engine.com>
Cc: S Boucher <stbya <at> yahoo.com>, Chong Yidong <cyd <at> stupidchicken.com>,
	Eric Ludlam <zappo <at> gnu.org>, 6967 <at> debbugs.gnu.org
Subject: Re: bug#6967: flymake not cleaning after itself (kill-buffer)
Date: Mon, 25 Oct 2010 12:20:45 -0400
> 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):

From: S Boucher <stbya <at> yahoo.com>
To: Chong Yidong <cyd <at> stupidchicken.com>,
	"Eric M. Ludlam" <eric <at> siege-engine.com>
Cc: Eric Ludlam <zappo <at> gnu.org>, 6967 <at> debbugs.gnu.org
Subject: Re: bug#6967: flymake not cleaning after itself (kill-buffer)
Date: Mon, 25 Oct 2010 14:54:27 -0700 (PDT)
> 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.