bug#68570: 29.1; recompile might not re-use project-compile's buffer

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 68570@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 02 May 2024 09:16:40 +0300
> 
> >>> We could make a new option in compile.el which would determine whether to
> >>> do this in general: when non-nil, 'compilation-start' would save the
> >>> current dynamic value of 'compilation-buffer-name-function', and
> >>> 'recompile' would call it again.
> >> A new option would be nice, but it's so broken that I don't know
> >> if it helps.  For example, 'M-x compile RET' in a compilation buffer
> >> doesn't prefill the minibuffer with the current compilation command,
> >> but uses the default command that makes no sense.
> >
> > If it did so (pre-filled the command), perhaps you would just use 'M-x
> > compile', in cases when you do want the new buffer to be created?
> >
> > But it seems to work fine to me, including in 'emacs -Q':
> >
> > * 'M-x compile', input 'ls', RET.
> > * *compilation* buffer create.
> > * 'M-x compile' again, in any window (old or new) - 'ls' is pre-filled as
> >  the input.
> 
> Sorry for the delay, I tried to fix it, but it's too much broken.
> Here is the test case for 'emacs -Q':
> 1. add such line to .dir-locals.el:
>   ((nil . ((compile-command . "ls -la"))))
> 2. M-x compile
> 3. confirm that it's "ls -la" indeed
> 4. edit the minibuffer, replace "ls -la" with e.g. "ls" and type RET
> 5. in *compilation* buffer again type: M-x compile
> 6. the minibuffer contains "make -k "

I'm not sure I agree that this makes no sense.  We have the
"M-x recompile" command for a reason.  "M-x compile" can be
used after running a compilation command once or more, and
it is not outlandish for "M-x compile" to return to the original
default value, to allow running more than a single compilation
conveniently, without too much editing in the minibuffer.

> PS: I realized now this is related to bug#70136
> where Augusto posted the patch that fixes this bug.

Re-reading the dir-locals each time a command is run might not
always make sense, IMO.

IOW, beware: these suggestions change the long-time behavior of
Emacs, so we should do that only very cautiously, and we shouldn't
be surprised if someone then comes back complaining that we broke
their muscle memory.  The notion that some behavior which makes no
sense to me or you or Augusto is necessarily a bug is IME
fundamentally flawed, since (as we all should know) most things in
Emacs are the result of careful thinking and moreover withstood
testing by many users for many years.  We may not always see the
logic behind the existing behavior, but we should always assume
there is some non-trivial logic.