GNU bug report logs -
#78719
30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion'
Previous Next
Full log
Message #65 received at 78719 <at> debbugs.gnu.org (full text, mbox):
Phil Sainty <psainty <at> orcon.net.nz> 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
This bug report was last modified 57 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.