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

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

[Jörg Bornemann]

One can use project-compile to build a project and then call recompile
to repeat the compilation.  This reuses the buffer named
"*compilation*".

If I set project-compilation-buffer-name-function to
#'project-prefixed-buffer-name, this creates a compilation buffer
"*myproject-compilation*" when executing project-compile.  Now,
recompile won't re-use "*myproject-compilation*" but create a new
buffer "*compilation*".

To reproduce this behavior, it is enough to start Emacs like this:
$ emacs -Q --eval "(setq project-compilation-buffer-name-function 
#'project-prefixed-buffer-name)"

It would be nice if recompile could re-use project-compile's buffer 
name.  I have fixed this locally by setting 
compilation-buffer-name-function like this:

---snip---
   (defun my-compilation-buffer-name (name-of-mode)
     (if (project-current)
         (apply project-compilation-buffer-name-function (list 
name-of-mode))
       (compilation--default-buffer-name name-of-mode)))

   (setq compilation-buffer-name-function #'my-compilation-buffer-name)
---snap---

Although I'm thinking by now that it might be more consistent to have a 
separate project-recompile command in addition to
recompile.

What do you think?  On one hand is the above fix quite convenient but on 
the other, compilation-buffer-name-function probably should not have 
project.el-specific knowledge.

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

[Pengji Zhang]

Hi!

I think you meant running `M-x recompile' not in a compilation buffer?
While I agree that is convenient, I suppose it is better to only use
`recompile' in a compilation buffer due to security reasons.

`compile-command' is marked as a safe local variable assuming that the
user would be prompted to check and confirm the command before running
it. That is the behavior of `compile' but not `recompile'. For
example, create a file '/tmp/test.c' with the following contents:

    /* Local Variables: */
    /* compile-command: "echo 1" */
    /* End: */

Then:
  - emacs -Q --eval "(require 'compile)"
  - C-x C-f /tmp/test.c
  - M-x recompile

So we could run arbitrary commands without any warning or confirmation.

Instead of a `project-recompile' command, it might be better to make
`recompile' find the existing compilation buffer for the current
buffer, and refuse to run the command (or ask for confirmation) if
there is no such buffer.

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

[Dmitry Gutov]

On 19/01/2024 22:19, Pengji Zhang wrote:
> I think you meant running `M-x recompile' not in a compilation buffer?
> While I agree that is convenient, I suppose it is better to only use
> `recompile' in a compilation buffer due to security reasons.
> 
> `compile-command' is marked as a safe local variable assuming that the
> user would be prompted to check and confirm the command before running
> it. That is the behavior of `compile' but not `recompile'. For
> example, create a file '/tmp/test.c' with the following contents:
> 
>      /* Local Variables: */
>      /* compile-command: "echo 1" */
>      /* End: */
> 
> Then:
>    - emacs -Q --eval "(require 'compile)"
>    - C-x C-f /tmp/test.c
>    - M-x recompile
> 
> So we could run arbitrary commands without any warning or confirmation.

It seems like you found a security issue in 'M-x recompile'. It's 
orthogonal to this feature request, though.

> Instead of a `project-recompile' command, it might be better to make
> `recompile' find the existing compilation buffer for the current
> buffer, and refuse to run the command (or ask for confirmation) if
> there is no such buffer.

This sounds like a good plan for fixing the above issue.

But the step "find the existing compilation buffer for the current 
buffer" requires compilation-buffer-name-function to be set to an 
appropriate value. And project-compile only binds it temporarily.

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

[Dmitry Gutov]

On 18/01/2024 18:17, Jörg Bornemann wrote:
> Although I'm thinking by now that it might be more consistent to have a 
> separate project-recompile command in addition to
> recompile.

I've pushed to master a new command called that (commit 0a07603ae8d), 
like discussed on the mailing list.

Not sure if we should close this report now, or perhaps keep it open to 
discuss the security issue.

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

[Juri Linkov]

>> Although I'm thinking by now that it might be more consistent to have
>> a separate project-recompile command in addition to
>> recompile.
>
> I've pushed to master a new command called that (commit 0a07603ae8d), like
> discussed on the mailing list.

Shouldn't now 'g' in project buffers use 'project-recompile'?

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

[Dmitry Gutov]

On 21/01/2024 20:18, Juri Linkov wrote:
>>> Although I'm thinking by now that it might be more consistent to have
>>> a separate project-recompile command in addition to
>>> recompile.
>> I've pushed to master a new command called that (commit 0a07603ae8d), like
>> discussed on the mailing list.
> Shouldn't now 'g' in project buffers use 'project-recompile'?

I don't know if it should - AFAICS 'M-x recompile' doesn't rename the 
current buffer, so it seems like the current behavior is already correct.

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

[Juri Linkov]

>>>> Although I'm thinking by now that it might be more consistent to have
>>>> a separate project-recompile command in addition to
>>>> recompile.
>>> I've pushed to master a new command called that (commit 0a07603ae8d), like
>>> discussed on the mailing list.
>> Shouldn't now 'g' in project buffers use 'project-recompile'?
>
> I don't know if it should - AFAICS 'M-x recompile' doesn't rename the
> current buffer, so it seems like the current behavior is already correct.

This patch would allow 'recompile' to use the renamed project compilation buffer:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ab4504fa027..58bf2401dac 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1395,7 +1395,10 @@ project-compile
         (compilation-buffer-name-function
          (or project-compilation-buffer-name-function
              compilation-buffer-name-function)))
-    (call-interactively #'compile)))
+    (with-current-buffer (call-interactively #'compile)
+      (when project-compilation-buffer-name-function
+        (setq-local compilation-buffer-name-function
+                    project-compilation-buffer-name-function)))))
 
 (defun project-recompile (&optional edit-command)
   "Run `recompile' with appropriate buffer."

Then 'project-recompile' won't be needed anymore.

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

[Jörg Bornemann]

On 1/22/24 08:31, Juri Linkov wrote:

> This patch would allow 'recompile' to use the renamed project compilation buffer:
> 
[...]
> 
> Then 'project-recompile' won't be needed anymore.

IIUC that sets `compilation-buffer-name-function' in the buffer that was 
active when you ran `project-compile'.  If you run `recompile' in 
another buffer of the project then `recompile' won't re-use the 
`project-compile' buffer.

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

[Dmitry Gutov]

On 22/01/2024 10:42, Jörg Bornemann wrote:
> On 1/22/24 08:31, Juri Linkov wrote:
> 
>> This patch would allow 'recompile' to use the renamed project 
>> compilation buffer:
>>
> [...]
>>
>> Then 'project-recompile' won't be needed anymore.
> 
> IIUC that sets `compilation-buffer-name-function' in the buffer that was 
> active when you ran `project-compile'.  If you run `recompile' in 
> another buffer of the project then `recompile' won't re-use the 
> `project-compile' buffer.

Yes, that doesn't sound optimal.

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

[Juri Linkov]

>> This patch would allow 'recompile' to use the renamed project compilation buffer:
>>
> [...]
>> Then 'project-recompile' won't be needed anymore.
>
> IIUC that sets `compilation-buffer-name-function' in the buffer that was
> active when you ran `project-compile'.  If you run `recompile' in another
> buffer of the project then `recompile' won't re-use the `project-compile'
> buffer.

Recompiling from a non-compilation buffer has security concerns.

The patch that I proposed above is intended only for
recompiling from a compilation buffer.  It sets
`compilation-buffer-name-function' in the compilation buffer.

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

[Dmitry Gutov]

On 23/01/2024 09:09, Juri Linkov wrote:
>>> This patch would allow 'recompile' to use the renamed project compilation buffer:
>>>
>> [...]
>>> Then 'project-recompile' won't be needed anymore.
>> IIUC that sets `compilation-buffer-name-function' in the buffer that was
>> active when you ran `project-compile'.  If you run `recompile' in another
>> buffer of the project then `recompile' won't re-use the `project-compile'
>> buffer.
> Recompiling from a non-compilation buffer has security concerns.
> 
> The patch that I proposed above is intended only for
> recompiling from a compilation buffer.  It sets
> `compilation-buffer-name-function' in the compilation buffer.

I think it behaves correctly inside the compilation buffer already? At 
least it did when I tested.

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

[Jörg Bornemann]

On 1/23/24 13:21, Dmitry Gutov wrote:

>> The patch that I proposed above is intended only for
>> recompiling from a compilation buffer.  It sets
>> `compilation-buffer-name-function' in the compilation buffer.
> 
> I think it behaves correctly inside the compilation buffer already? At 
> least it did when I tested.

Yes.  I can confirm that pressing g in a compilation buffer that's named 
by project-compilation-name-buffer-function is already working correctly.

After reading Pengji's security concern (thanks Dmitry for pointing me 
to it) I also think that it would be more favorable to let recompile 
re-use a compilation buffer.  That would indeed make project-recompile 
superfluous.

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

[Dmitry Gutov]

On 23/01/2024 15:15, Jörg Bornemann wrote:
> After reading Pengji's security concern (thanks Dmitry for pointing me 
> to it) I also think that it would be more favorable to let recompile 
> re-use a compilation buffer.  That would indeed make project-recompile 
> superfluous.

I don't know if it would: the compilation buffer might not be the only 
one - or the existing one might not belong to the current project.

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

[Juri Linkov]

>> Recompiling from a non-compilation buffer has security concerns.
>> The patch that I proposed above is intended only for
>> recompiling from a compilation buffer.  It sets
>> `compilation-buffer-name-function' in the compilation buffer.
>
> I think it behaves correctly inside the compilation buffer already? At
> least it did when I tested.

Sorry, I didn't show my compilation function:

(setopt project-compilation-buffer-name-function
        (lambda (name-of-mode)
          (generate-new-buffer-name
           (project-prefixed-buffer-name name-of-mode))))

Currently 'g' doesn't create a new compilation buffer, because
'compilation--default-buffer-name' just reuses the current buffer.

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

[Dmitry Gutov]

On 24/01/2024 09:46, Juri Linkov wrote:
>>> Recompiling from a non-compilation buffer has security concerns.
>>> The patch that I proposed above is intended only for
>>> recompiling from a compilation buffer.  It sets
>>> `compilation-buffer-name-function' in the compilation buffer.
>> I think it behaves correctly inside the compilation buffer already? At
>> least it did when I tested.
> Sorry, I didn't show my compilation function:
> 
> (setopt project-compilation-buffer-name-function
>          (lambda (name-of-mode)
>            (generate-new-buffer-name
>             (project-prefixed-buffer-name name-of-mode))))
> 
> Currently 'g' doesn't create a new compilation buffer, because
> 'compilation--default-buffer-name' just reuses the current buffer.

Is that bad?

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

[Juri Linkov]

>>>> Recompiling from a non-compilation buffer has security concerns.
>>>> The patch that I proposed above is intended only for
>>>> recompiling from a compilation buffer.  It sets
>>>> `compilation-buffer-name-function' in the compilation buffer.
>>> I think it behaves correctly inside the compilation buffer already? At
>>> least it did when I tested.
>> Sorry, I didn't show my compilation function:
>> (setopt project-compilation-buffer-name-function
>>          (lambda (name-of-mode)
>>            (generate-new-buffer-name
>>             (project-prefixed-buffer-name name-of-mode))))
>> Currently 'g' doesn't create a new compilation buffer, because
>> 'compilation--default-buffer-name' just reuses the current buffer.
>
> Is that bad?

It's very useful to always create a unique buffer for every compilation:
this allows keeping error messages from previous compilations.
I propose even to add such an option to the choice list in
project-compilation-buffer-name-function, e.g.:

(defcustom project-compilation-buffer-name-function nil
  :type '(choice (const :tag "Default" nil)
                 (const :tag "Prefixed with project name"
                        project-prefixed-buffer-name)
                 (const :tag "Prefixed and unique with project name"
                        project-prefixed-unique-buffer-name)
                 (function :tag "Custom function")))

The previous patch would be needed as well since currently
there is no way to allow unique project compilation buffers.

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

[Dmitry Gutov]

On 24/01/2024 19:11, Juri Linkov wrote:
>>>>> Recompiling from a non-compilation buffer has security concerns.
>>>>> The patch that I proposed above is intended only for
>>>>> recompiling from a compilation buffer.  It sets
>>>>> `compilation-buffer-name-function' in the compilation buffer.
>>>> I think it behaves correctly inside the compilation buffer already? At
>>>> least it did when I tested.
>>> Sorry, I didn't show my compilation function:
>>> (setopt project-compilation-buffer-name-function
>>>           (lambda (name-of-mode)
>>>             (generate-new-buffer-name
>>>              (project-prefixed-buffer-name name-of-mode))))
>>> Currently 'g' doesn't create a new compilation buffer, because
>>> 'compilation--default-buffer-name' just reuses the current buffer.
>>
>> Is that bad?
> 
> It's very useful to always create a unique buffer for every compilation:
> this allows keeping error messages from previous compilations.

Hmm, but I suppose it can be a personal preference whether a "recompile" 
should create a new buffer or not.

Because it's also reasonable to expect that 'M-x compile' creates a new 
buffer (e.g. project-prefixed and unique), but 'recompile', or 
'revert-buffer' - keep that buffer around and reuse it. When one wants 
to keep the old contents, they could 'M-x compile' (or 'M-x 
project-compile') instead.

This might be my preference anyway, because OT1H old compilations are 
often (but not always) handy to have around, OT2H I don't like to have 
too many buffers, and the above distinction between 'compile' and 
'recompile' would be a tool to make that choice.

> I propose even to add such an option to the choice list in
> project-compilation-buffer-name-function, e.g.:
> 
> (defcustom project-compilation-buffer-name-function nil
>    :type '(choice (const :tag "Default" nil)
>                   (const :tag "Prefixed with project name"
>                          project-prefixed-buffer-name)
>                   (const :tag "Prefixed and unique with project name"
>                          project-prefixed-unique-buffer-name)
>                   (function :tag "Custom function")))

Sounds good.

> The previous patch would be needed as well since currently
> there is no way to allow unique project compilation buffers.

The one in 0a07603ae8d?

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

[Juri Linkov]

>> It's very useful to always create a unique buffer for every compilation:
>> this allows keeping error messages from previous compilations.
>
> Hmm, but I suppose it can be a personal preference whether a "recompile"
> should create a new buffer or not.
>
> Because it's also reasonable to expect that 'M-x compile' creates a new
> buffer (e.g. project-prefixed and unique), but 'recompile', or
> 'revert-buffer' - keep that buffer around and reuse it. When one wants to
> keep the old contents, they could 'M-x compile' (or 'M-x project-compile')
> instead.
>
> This might be my preference anyway, because OT1H old compilations are often
> (but not always) handy to have around, OT2H I don't like to have too many
> buffers, and the above distinction between 'compile' and 'recompile' would
> be a tool to make that choice.

A new option could be added indeed.  But currently 'g' after 'compile'
uses 'compilation-buffer-name-function' that can be configured
to generate a new buffer.  So it's expected that 'g' after
'project-compile' should do the same and use
'project-compilation-buffer-name-function', especially
when it's configured to generate a new buffer.

IOW, I think these two 'compile' and 'project-compile'
should be in sync in regard to what 'recompile' does.

>> I propose even to add such an option to the choice list in
>> project-compilation-buffer-name-function, e.g.:
>> (defcustom project-compilation-buffer-name-function nil
>>    :type '(choice (const :tag "Default" nil)
>>                   (const :tag "Prefixed with project name"
>>                          project-prefixed-buffer-name)
>>                   (const :tag "Prefixed and unique with project name"
>>                          project-prefixed-unique-buffer-name)
>>                   (function :tag "Custom function")))
>
> Sounds good.

There is also a proposal to add the same option
to 'compilation-buffer-name-function' in bug#68697.

>> The previous patch would be needed as well since currently
>> there is no way to allow unique project compilation buffers.
>
> The one in 0a07603ae8d?

Actually I meant https://debbugs.gnu.org/68570#23

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

[Dmitry Gutov]

On 27/01/2024 19:53, Juri Linkov wrote:
>>> It's very useful to always create a unique buffer for every compilation:
>>> this allows keeping error messages from previous compilations.
>>
>> Hmm, but I suppose it can be a personal preference whether a "recompile"
>> should create a new buffer or not.
>>
>> Because it's also reasonable to expect that 'M-x compile' creates a new
>> buffer (e.g. project-prefixed and unique), but 'recompile', or
>> 'revert-buffer' - keep that buffer around and reuse it. When one wants to
>> keep the old contents, they could 'M-x compile' (or 'M-x project-compile')
>> instead.
>>
>> This might be my preference anyway, because OT1H old compilations are often
>> (but not always) handy to have around, OT2H I don't like to have too many
>> buffers, and the above distinction between 'compile' and 'recompile' would
>> be a tool to make that choice.
> 
> A new option could be added indeed.  But currently 'g' after 'compile'
> uses 'compilation-buffer-name-function' that can be configured
> to generate a new buffer.  So it's expected that 'g' after
> 'project-compile' should do the same and use
> 'project-compilation-buffer-name-function', especially
> when it's configured to generate a new buffer.

Again, I'm not sure if it's expected: even if I do like the idea of 
unique per-project compilation buffers, seeing 'g' reuse the existing 
buffer feels pretty natural.

> IOW, I think these two 'compile' and 'project-compile'
> should be in sync in regard to what 'recompile' does.

When I'm saying is that when 'recompile' reuses the current buffer it 
already follows the result of project-compilation-buffer-name-function 
(when it was invoked from project-compile, of course).

>>> I propose even to add such an option to the choice list in
>>> project-compilation-buffer-name-function, e.g.:
>>> (defcustom project-compilation-buffer-name-function nil
>>>     :type '(choice (const :tag "Default" nil)
>>>                    (const :tag "Prefixed with project name"
>>>                           project-prefixed-buffer-name)
>>>                    (const :tag "Prefixed and unique with project name"
>>>                           project-prefixed-unique-buffer-name)
>>>                    (function :tag "Custom function")))
>>
>> Sounds good.
> 
> There is also a proposal to add the same option
> to 'compilation-buffer-name-function' in bug#68697.

Sounds good to me. We could also ask the reporter there what they think 
'g' should do in such buffers (create a new one or reuse current).

>>> The previous patch would be needed as well since currently
>>> there is no way to allow unique project compilation buffers.
>>
>> The one in 0a07603ae8d?
> 
> Actually I meant https://debbugs.gnu.org/68570#23

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.

Otherwise the distinction remains that when 'recompile' is invoked 
inside a compilation buffer, the same buffer is used; and when it's 
invoked from some other buffer, a new compilation buffer can be created.

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

[Juri Linkov]

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

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

[Dmitry Gutov]

On 06/02/2024 19:39, Juri Linkov wrote:
>> 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.

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

[Juri Linkov]

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

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

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

[Eli Zaretskii]

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

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

[Jörg Bornemann]

On 1/21/24 06:09, Dmitry Gutov wrote:

> I've pushed to master a new command called that (commit 0a07603ae8d), 
> like discussed on the mailing list.

Thanks!

> Not sure if we should close this report now, or perhaps keep it open to 
> discuss the security issue.

What security concerns do you have?

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

[Dmitry Gutov]

On 22/01/2024 10:39, Jörg Bornemann wrote:
>> Not sure if we should close this report now, or perhaps keep it open 
>> to discuss the security issue.
> 
> What security concerns do you have?

The one mentioned by Penji Zhang in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68570#8

I suppose he didn't Cc you, so you didn't see the message.