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

Previous Next

To reply to this bug, email your comments to 68570 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jörg Bornemann <foss <at> jbornemann.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; recompile might not re-use project-compile's buffer
Date: Thu, 18 Jan 2024 17:17:07 +0100

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.

Message #8 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Pengji Zhang <kunhtkun <at> gmail.com>
To: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1;
 recompile might not re-use project-compile's buffer
Date: Fri, 19 Jan 2024 15:19:08 -0500

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.

Message #11 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Pengji Zhang <kunhtkun <at> gmail.com>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Sat, 20 Jan 2024 16:27:58 +0200

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.

Message #14 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Sun, 21 Jan 2024 07:09:31 +0200

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.

Message #17 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Jörg Bornemann <foss <at> jbornemann.de>,
 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Sun, 21 Jan 2024 20:18:44 +0200

>> 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'?

Message #20 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Sun, 21 Jan 2024 20:33:00 +0200

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.

Message #23 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Jörg Bornemann <foss <at> jbornemann.de>,
 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Mon, 22 Jan 2024 09:31:22 +0200

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

Message #26 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Jörg Bornemann <foss <at> jbornemann.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Mon, 22 Jan 2024 09:39:29 +0100

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?

Message #29 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Jörg Bornemann <foss <at> jbornemann.de>
To: Juri Linkov <juri <at> linkov.net>, Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Mon, 22 Jan 2024 09:42:53 +0100

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.

Message #32 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Mon, 22 Jan 2024 20:20:13 +0200

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.

Message #35 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Jörg Bornemann <foss <at> jbornemann.de>,
 Juri Linkov <juri <at> linkov.net>
Cc: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Mon, 22 Jan 2024 20:20:36 +0200

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.

Message #38 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Jörg Bornemann <foss <at> jbornemann.de>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Tue, 23 Jan 2024 09:09:28 +0200

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

Message #41 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>, Jörg Bornemann
 <foss <at> jbornemann.de>
Cc: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Tue, 23 Jan 2024 14:21:50 +0200

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.

Message #44 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Jörg Bornemann <foss <at> jbornemann.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Juri Linkov <juri <at> linkov.net>
Cc: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Tue, 23 Jan 2024 14:15:36 +0100

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.

Message #47 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Jörg Bornemann <foss <at> jbornemann.de>,
 Juri Linkov <juri <at> linkov.net>
Cc: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Tue, 23 Jan 2024 19:31:55 +0200

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.

Message #50 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Jörg Bornemann <foss <at> jbornemann.de>,
 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Wed, 24 Jan 2024 09:46:51 +0200

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

Message #53 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Wed, 24 Jan 2024 14:06:57 +0200

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?

Message #56 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Jörg Bornemann <foss <at> jbornemann.de>,
 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Wed, 24 Jan 2024 19:11:35 +0200

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

Message #59 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Fri, 26 Jan 2024 02:44:17 +0200

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?

Message #62 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Jörg Bornemann <foss <at> jbornemann.de>,
 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Sat, 27 Jan 2024 19:53:34 +0200

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

Message #65 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Sun, 28 Jan 2024 15:42:10 +0200

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.

Message #68 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Jörg Bornemann <foss <at> jbornemann.de>,
 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Tue, 06 Feb 2024 19:39:27 +0200

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

Message #71 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Jörg Bornemann <foss <at> jbornemann.de>, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
Date: Wed, 7 Feb 2024 20:43:41 +0200

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.

Message #74 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1; recompile might not re-use project-compile's
 buffer
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 "

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

Message #77 received at 68570 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: dmitry <at> gutov.dev, 68570 <at> debbugs.gnu.org
Subject: Re: bug#68570: 29.1;
 recompile might not re-use project-compile's buffer
Date: Thu, 02 May 2024 10:11:53 +0300

> Cc: 68570 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.