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

Previous Next

Full log

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, juri <at> linkov.net, 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: Sun, 06 Jul 2025 02:04:27 +1200

On 2025-07-06 01:15, Daniel Mendler wrote:
> 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.

I'm not talking about the complexity of the functionality, but rather
the complexity of *using* the function.

I'm arguing that if you're not trying to write completion code, it's
horrible to have to write (and read) this:

  (let* ((completion-ignore-case nil)
         (completion-regexp-list regexp-list)
         (prefix (try-completion "" collection)))
    (if (stringp prefix)
        prefix
      (if (eq t prefix)
          string
        ""))))

when it can simply be:

  (string-common-prefix collection nil nil regexp-list)

I'm talking about eliminating the awkwardness both of setting up
the call and of dealing with the completion-centric return values;
I'm not talking about "unnecessary awkward arguments" -- I never
saw any problem with the feature set of try-completion.  The
problem is that it's not a reasonable API to use *outside* of
completion, because it's specifically targeting completion.

I don't believe we're going to agree on this, and I see that Eli
has responded and remains in agreement with you; so I although I
remain baffled (as I consider that the additional features were
useful, and that the *optional* arguments I added to support them
were *easy* to understand from the documentation), I shan't
continue the argument.

I'll respond to Eli, and will reduce the new function to only the
simplest case.


-Phil

Previous Next

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