bug#12288: 24.2.50; compilation-start: Query for killing existing compilation process only if query-on-exit-flag is non-nil

[Martin Blais]

On Sat, Sep 1, 2012, at 11:29, Christopher Schmidt wrote:
> Martin Blais <blais@furius.ca> writes:
> > I'm not sure I understand. Let's recap a bit:
> >
> > a. in 'compilation-start-hook, there's a hint that you can force the
> > process-query-on-exit-flag on the compile process; that would
> > presumably allow you to kill the buffer without a query, but not on a
>                                                            ^^^^^^^^^^^^
> > subsequent call to compile. (BTW I just tried the suggested hook as is
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > and it doesn't work for me, but that's another issue).
> 
> This is exactly what I don't want.
> 
> Those processes that have a nil query-on-exit-flag should be killed by
> compilation-start without a yes-or-no query.  A buffer-local non-nil
> value for compilation-always-kill allows me to achieve that.
> 
> I still think a check for query-on-exit-flag in compilation-start is a
> good idea.  Non-nil query-on-exit-flag and non-nil buffer-local
> compilation-always-kill feels redundant, doesn't it?

Maybe what we should do is this (just an idea, not sure if it'll make sense to
you):

1. Make the compile code check the process-query-on-exit-flag instead of the
   compilation-always-kill variable. This would simplify matters, in that
   there's a single flag that decides whether to kill the running process, and
   it's the same flag that's already being used for when you kill a buffer. One
   thing.

2. Provide a way to set the default value of process-query-on-exit-flag on
   compile subprocesses easier than the hook/comment. Suppressing the ask on
   recompile is a very common desire BTW--some people have packages to do just
   that--and IMO being able to customize this via a dedicated variable is
   valuable.

What do you think?