Subject: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion'

From: Daniel Mendler <[email-masked]>
Date: Tue, 10 Jun 2025 11:48:13 +0200

Phil Sainty <[email-masked]> writes:

> On 2025-06-09 22:56, Daniel Mendler wrote:
>
>> Stefan Monnier <[email-masked]> writes:
>> > Do we have reasons to believe callers will want/need those
>> > `&key` arguments?  My gut tells me we don't need the
>> > `predicate` and `regexps` options.
>> Yes, I think it makes sense to only offer the simplest
>> function without additional features, since the goal is a
>> simpler API after all to obtain common prefixes.
>> (defun string-common-prefix (strings &key ignore-case))
>> If additional completion features are needed, we can refer
>> the user to `try-completion' in the docstring or the manual.
>
> We essentially get that extra functionality for free, so I see
> no reason not to leverage that by supporting it in the new
> function.

Additional features are not completely free. If you add complexity to a
new function `string-common-prefix', it gets harder to understand and
use. Given that we already have `try-completion', one can use that if
one wants to use additional regular expressions. The goal is to provide
a simple API to compute the common prefix of a list of strings, not to
dress `try-completion' differently. Therefore my favorite function looks
like this:

(defun string-common-prefix (strings &key ignore-case))

> My original two-function approach was to provide that 'simplest'
> function while also ensuring that the extra features were still
> available without callers having to account for the various
> non-string return values from `try-completion'.  So I don't like
> the idea of `try-completion' being the only option for someone
> who wants to use the extra features.

Yes, but introducing a second function `string-try-completion' with the
single purpose of having a uniform string return type (and without
dynamic variables) does not seem worth it. Then I would rather go with
the single function.

> I'm happy to go with the single function approach, as the
> cl-defun approach keeps the API simple in the simple case, but
> I think the extra keywords should be supported.  I'm happy to
> implement that.

Yes, this is better than the two functions, even if I still favor the
simpler function as mentioned above.

> -Phil