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

["Eric M. Ludlam" <eric@siege-engine.com>]

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