Philip Kaludercic wrote: >> From 7e140c1ab5bfc7440753ab3aff2c3ce7eb38414e Mon Sep 17 00:00:00 2001 >> From: Spyros Roum >> 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).