Philip Kaludercic wrote:
From 7e140c1ab5bfc7440753ab3aff2c3ce7eb38414e Mon Sep 17 00:00:00 2001
From: Spyros Roum <spyros.roum@posteo.net>
Date: Wed, 25 Dec 2024 17:32:31 +0200
Subject: [PATCH] Add option for making compilation-read-command use
 completing-read

* etc/NEWS: Add to NEWS
* lisp/progmodes/compile.el (compilation-read-command):
Call function based on `compilation-read-command-function`.

(compilation-prompt-read-shell-command): The existing
functionality from compilation-read-command extracted to
a function.

(compilation-prompt-read-with-history-completion): A
function that uses completing-read to read the command.

(compilation-read-command-function): The new option that
controlls which function is used.
The detail seems fine, the formatting is just unusual but that can be
fixed when applying the patch.
Oops... I looked into the ChangeLog to find similar examples and
if I understand correctly, the major difference is that I have blank lines between
changes that happened in the same file, so I removed those.

Like I read somewhere: it can be fixed at apply time, but it's best to get it right the first time.

---
 etc/NEWS                  |  8 ++++++++
 lisp/progmodes/compile.el | 28 +++++++++++++++++++++++++++-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/etc/NEWS b/etc/NEWS
index ca107bb4938..cfb137c2399 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -147,6 +147,14 @@ will still be on that candidate after "*Completions*" is updated with a
 new list of completions.  The candidate is automatically deselected when
 the "*Completions*" buffer is hidden.
 
+---
+*** New user option 'compilation-read-command-function'.
+This option controls what function is used to read user input for
+'compilation-read-command'.
+It defaults to 'compilation-prompt-read-shell-command', which preserves
+existing behavior.  When set to 'compilation-prompt-read-with-history-completion',
+'completing-read' is used allowing autocomplete based on past runs of 'compile'.
I am not sure if we need to go into the options here.

I based the entry on a similar entry from a few lines up:

  > *** New user option 'completion-pcm-leading-wildcard'.
  > This option configures how the partial-completion style does completion.
  > It defaults to nil, which preserves the existing behavior.  When it is set
  > to t, the partial-completion style behaves more like the substring
  > style, in that a string being completed can match against a candidate
  > anywhere in the candidate string.

If you think however that the options are not necessary, I can keep the first sentence only.

Patch attached has the corrected `:version` and ChangeLog, no other changes (also rebased to master).