GNU bug report logs - #78719
30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion'

Previous Next

Full log

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: eliz <at> gnu.org, juri <at> linkov.net, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 drew.adams <at> oracle.com, 78719 <at> debbugs.gnu.org
Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix'
 and `string-try-completion'
Date: Tue, 10 Jun 2025 11:48:13 +0200

Phil Sainty <psainty <at> orcon.net.nz> writes:

> On 2025-06-09 22:56, Daniel Mendler wrote:
>
>> Stefan Monnier <monnier <at> iro.umontreal.ca> 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

Previous Next

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