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

Previous Next

Full log

View this message in rfc822 format

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mail <at> daniel-mendler.de, juri <at> linkov.net, monnier <at> iro.umontreal.ca, drew.adams <at> oracle.com, 78719 <at> debbugs.gnu.org
Subject: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion'
Date: Sun, 06 Jul 2025 02:46:38 +1200

I wanted to respond to the points here, but I'm also conceding on the
inclusion of the filtering arguments, and will simplify the new function
accordingly.


On 2025-07-06 01:36, Eli Zaretskii wrote:
>> I don't like "leave the rest to try-completion" because try-completion
>> is really awkward to use outside of a completion context.
> 
> How can you say that, when the body of the new function is just this:
> 
>   (let* ((completion-ignore-case ignore-case)
>          (completion-regexp-list regexp-list)
>          (prefix (try-completion (or string "") collection predicate)))
>     (if (stringp prefix)
>         prefix
>       (if (eq t prefix)
>           string
>         "")))

We could probably level that argument at many hundreds of existing
functions which are similarly small!

A wrapper doesn't need to be a large amount of code to be worthwhile.


> AFAIU, the single most important argument for having a new function
> (instead of telling people to do the above inline) is to simplify the
> calling sequence when all a program wants is a common prefix of a set
> of strings.

Agreed 100%.


> If all the facilities provided by try-completion need to
> be exposed by this new function, doesn't that make our rationale
> pretty much void?

I don't think so (but I'm in the minority in the current discussion).


> Because the above "complexity" pales near the need
> to understand the role and effects of each of the arguments.

The extra arguments required only as much time and effort to understand
as was needed to read the following paragraph:

 "The optional arguments STRING, REGEXP-LIST, and PREDICATE all provide
 ways of filtering out unwanted members of COLLECTION before determining
 the longest common prefix for the remaining members."

Having read that, I believe that users *not* wanting to "[filter] out
unwanted members of COLLECTION" would have needed a handful of seconds
at most to skim past the rest of the related information, so I'm just
not seeing the increase in complexity for the user that yourself and
Daniel are seeing.

I accept that I've not swayed anyone to my viewpoint, though, so I'm
going to remove the filter arguments and reduce the function to 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.