bug#6967: flymake not cleaning after itself (kill-buffer)

bug#6967: flymake not cleaning after itself (kill-buffer)

[S Boucher]

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.

bug#6967: flymake not cleaning after itself (kill-buffer)

[Chong Yidong]

S Boucher <stbya@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?

bug#6967: flymake not cleaning after itself (kill-buffer)

[Eric M. Ludlam]

On 10/24/2010 01:14 PM, Chong Yidong wrote:
> S Boucher<stbya@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

bug#6967: flymake not cleaning after itself (kill-buffer)

[Stefan Monnier]

> 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

bug#6967: flymake not cleaning after itself (kill-buffer)

[S Boucher]

> 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.