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

From: Daniel Mendler <[email-masked]>
Date: Sat, 05 Jul 2025 15:15:17 +0200

Phil Sainty <[email-masked]> writes:

> On 2025-07-06 00:35, Daniel Mendler wrote:
>> Only changing the return type to string is not worth the addition
>> of a new function.
>
> I can only disagree.  Wrapper functions which *eliminate all of the
> awkwardness* from an API are completely worthwhile.  They make the
> code using them easier to write and read and understand.

I agree that a wrapper has an advantage *if it eliminates all of the
awkwardness* from the API. Your proposed function fails at doing that
since it also provides all the unnecessary awkward arguments from the
underlying implementation.

That's why I am arguing for an even simpler API.

> My argument from the outset has been that try-completion is not a
> good API for use outside of the context of completion because of
> its return values, and therefore it warrants a wrapper which makes
> it nice to use (as well as easy to discover) for those situations.

I cannot agree that the return value of `try-complication' is overly
complicated. This is the description of the return value in the
docstring of `try-completion':

    If no possible completions match, the function returns nil; if
    there’s just one exact match, it returns t; otherwise it returns
    the longest initial substring common to all possible completions
    that begin with STRING.

Now compare that to the much longer description of the arguments:

    If COLLECTION is an alist, the keys (cars of elements) are the
    possible completions.  If an element is not a cons cell, then the
    element itself is a possible completion.
    If COLLECTION is a hash-table, all the keys that are either strings
    or symbols are the possible completions.
    If COLLECTION is an obarray, the names of all symbols in the obarray
    are the possible completions.

    COLLECTION can also be a function to do the completion itself.
    It receives three arguments: STRING, PREDICATE and nil.
    Whatever it returns becomes the value of try-completion.

    If optional third argument PREDICATE is non-nil, it must be a function
    of one or two arguments, and is used to test each possible completion.
    A possible completion is accepted only if PREDICATE returns non-nil.

    The argument given to PREDICATE is either a string or a cons cell (whose
    car is a string) from the alist, or a symbol from the obarray.
    If COLLECTION is a hash-table, PREDICATE is called with two arguments:
    the string key and the associated value.

    To be acceptable, a possible completion must also match all the regexps
    in completion-regexp-list (unless COLLECTION is a function, in
    which case that function should itself handle completion-regexp-list).

    If completion-ignore-case is non-nil, possible completions are matched
    while ignoring letter-case, but no guarantee is made about the letter-case
    of the return value, except that it comes either from the user’s input
    or from one of the possible completions.

Now you are proposing to wrap the function because of the "complicated"
return value, while the arguments are much more relevant in adding
complexity. If the point is to reduce the complexity via a wrapper, then
the arguments must be addressed too. One can always defer to
`try-completion' if the additional functionality is needed. For the
common use case of prefix computation, two arguments are sufficient, the
list of strings and IGNORE-CASE.

Daniel