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

Previous Next

To reply to this bug, email your comments to 78719 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>, juri <at> linkov.net
Subject: 30.1; [PATCH] Add functions `string-common-prefix' and
 `string-try-completion'
Date: Mon, 09 Jun 2025 00:03:46 +1200

This is a spin-off from bug#78658 -- and following on from
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78658#65 in particular --
to add friendlier alternatives to `try-completion' for efficiently
obtaining a common string prefix or completion from a collection of
strings outside of the context of minibuffer completion.

E.g. when you simply want to know the longest common prefix from a
list of strings without having to deal with any completion variables
or edge-case return values.

Unlike `try-completion' which may return nil or t, the new functions
always return a string, simplifying their usage and (on account of
the "string-*" naming) making the functionality more discoverable
for programmers working with strings.

The function `string-try-completion' provides the general case and
is just like `try-completion' except for always returning a string.

The function `string-common-prefix' is the simpler case wanted for
bug#78658, taking fewer arguments and binding the variables
`completion-regexp-list' and `completion-ignore-case'.

I've pushed a branch scratch/string-common-prefix with the following
commit for review:
https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?h=scratch/string-common-prefix&id=accfe19887f3573dd55f5272f92899afa1e2f446

(Plus a fixup commit removing the unintended additional NEWS entry.)


-Phil



In GNU Emacs 30.1 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2025-02-25 built on phil-lp
Repository revision: 8ac894e2246f25d2a2a97d866b10e6e0b0fede5a
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101004
System Description: Ubuntu 22.04.5 LTS

Configured using:
 'configure --prefix=/home/phil/emacs/30.x.nc/usr/local
 --with-native-compilation=aot --with-x-toolkit=lucid --without-sound
 '--program-transform-name=s/^ctags$/ctags_emacs/''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
X11 XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: en_NZ.UTF-8
  value of $LC_NUMERIC: en_NZ.UTF-8
  value of $LC_TIME: en_NZ.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8

Major mode: Magit Rev

Minor modes in effect:
  icomplete-mode: t
  magit-wip-initial-backup-mode: t
  magit-wip-before-change-mode: t
  magit-wip-after-apply-mode: t
  magit-wip-after-save-mode: t
  magit-wip-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  global-window-tool-bar-mode: t
  window-tool-bar-mode: t
  bug-reference-mode: t
  minibuffer-line-mode: t
  server-mode: t
  savehist-mode: t
  global-anzu-mode: t
  anzu-mode: t
  my-contextual-help-mode: t
  global-so-long-mode: t
  global-visible-mark-mode: t
  visible-mark-mode: t
  repeat-mode: t
  display-battery-mode: t
  my-visible-bell-mode: t
  global-display-fill-column-indicator-mode: t
  minibuffer-depth-indicate-mode: t
  which-key-mode: t
  keep-buffers-mode: t
  global-subword-mode: t
  subword-mode: t
  global-hl-line-mode: t
  display-time-mode: t
  recentf-mode: t
  my-global-keys-local-minor-mode: t
  my-keys-local-minor-mode: t
  windmove-mode: t
  url-handler-mode: t
  auto-compile-on-load-mode: t
  auto-compile-on-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-history-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/phil/.emacs.d/el-get/scratch/el-get hides 
/home/phil/.emacs.d/el-get/el-get/el-get
/home/phil/.emacs.d/el-get/avy/avy hides 
/home/phil/.emacs.d/elpa/avy-0.5.0/avy
/home/phil/.emacs.d/el-get/dash/dash hides 
/home/phil/.emacs.d/elpa/dash-2.19.1/dash
/home/phil/.emacs.d/el-get/iedit/iedit hides 
/home/phil/.emacs.d/elpa/iedit-0.9.9.9.9/iedit
/home/phil/.emacs.d/my-lisp/psysh hides 
/home/phil/.emacs.d/elpa/psysh-0.4.9/psysh
/home/phil/.emacs.d/elpa/transient-0.7.9/transient hides 
/home/phil/emacs/30.x.nc/usr/local/share/emacs/30.1/lisp/transient
/home/phil/.emacs.d/el-get/which-key/which-key hides 
/home/phil/emacs/30.x.nc/usr/local/share/emacs/30.1/lisp/which-key

Features:
(shadow sort ecomplete mail-extr emacsbug tramp trampver
tramp-integration tramp-message tramp-compat xdg parse-time iso8601
tramp-loaddefs term disp-table ehelp pcmpl-gnu pcmpl-unix sh-script smie
treesit two-column emacs-news-mode noutline outline cua-rect cua-base
find-dired whitespace reposition wgrep texinfo texinfo-loaddefs
dired-aux jinx magit-extras magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
ibuf-ext ibuffer ibuffer-loaddefs ucs-normalize shortdoc icomplete
face-remap hippie-exp executable files-x winnow magit-wip magit-log
which-func imenu magit-diff smerge-mode diff git-commit log-edit message
sendmail yank-media puny rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils
gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert
autorevert filenotify magit-margin magit-transient magit-process
with-editor shell pcomplete magit-mode transient edmacro magit-git
magit-section magit-utils crm dash misearch multi-isearch hi-lock
compare-w project find-func help-fns window-tool-bar tab-line compat
view mule-util holidays holiday-loaddefs cal-julian lunar solar cal-dst
vc-git diff-mode track-changes vc-dispatcher autoinsert bug-reference
goto-addr appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs
lexbind-mode hl-sexp fic-mode elide-head idle-highlight-mode
completion-preview sockit tabify minibuffer-line server my-org
my-projects my-session savehist desktop frameset my-mail my-libraries
sudo anzu my-version-control my-text my-programming so-long
my-rectangles rect my-utilities browse-kill-ring my-configuration
visible-mark cus-edit pp cus-load dired-details dired-x repeat
highlight-parentheses format-spec battery delight delsel ffap thingatpt
display-fill-column-indicator mb-depth which-key pcase easy-mmode
keep-buffers cap-words superword subword hl-line time recentf
tree-widget wid-edit atomic-chrome websocket bindat let-alist
my-whitespace ws-trim my-externals .loaddefs rainbow-mode notify dbus
xml mo-git-blame cl iedit el-get autoload loaddefs-gen radix-tree
lisp-mnt dired dired-loaddefs my-holidays my-local kmacro my-mahara grep
tks generic-x catalyst redshift-indent my-keybindings framemove advice
windmove my-startup-log time-date adaptive-wrap-autoloads ...)

Memory information:
((conses 16 1246250 374539) (symbols 48 43403 2)
 (strings 32 196192 27442) (string-bytes 1 7837076) (vectors 16 94255)
 (vector-slots 8 1904715 340289) (floats 8 927 9358)
 (intervals 56 128211 16974) (buffers 992 50))

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>, juri <at> linkov.net
Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and
 `string-try-completion'
Date: Sun, 08 Jun 2025 14:21:52 +0200

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

> This is a spin-off from bug#78658 -- and following on from
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78658#65 in particular --
> to add friendlier alternatives to `try-completion' for efficiently
> obtaining a common string prefix or completion from a collection of
> strings outside of the context of minibuffer completion.
>
> E.g. when you simply want to know the longest common prefix from a
> list of strings without having to deal with any completion variables
> or edge-case return values.
>
> Unlike `try-completion' which may return nil or t, the new functions
> always return a string, simplifying their usage and (on account of
> the "string-*" naming) making the functionality more discoverable
> for programmers working with strings.
>
> The function `string-try-completion' provides the general case and
> is just like `try-completion' except for always returning a string.

What is the purpose of having a separate function
`string-try-completion'? I think it is confusing if the function
respects the `completion-regexp-list' and `completion-ignore-case'
dynamic variables, and if we end up with three functions
`try-completion', `string-try-completion', and
`completions-try-completion'.

Why not only provide a single function `string-expand-prefix' with
additional keyword or optional arguments:

(cl-defun string-common-prefix (strings &key ignore-case regexps predicate))

The STRING or initial prefix argument seems redundant, since one can
always use the empty string, and use `string-prefix-p' to check a
desired prefix, or am I missing something?

(cl-defun string-common-prefix (strings &key prefix ignore-case regexps predicate))

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: psainty <at> orcon.net.nz, bug-gnu-emacs <at> gnu.org, drew.adams <at> oracle.com,
 juri <at> linkov.net
Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and
 `string-try-completion'
Date: Sun, 08 Jun 2025 15:35:03 +0300

> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Cc: bug-gnu-emacs <at> gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  Drew Adams
>  <drew.adams <at> oracle.com>,  juri <at> linkov.net
> Date: Sun, 08 Jun 2025 14:21:52 +0200
> 
> Phil Sainty <psainty <at> orcon.net.nz> writes:
> 
> > This is a spin-off from bug#78658 -- and following on from
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78658#65 in particular --
> > to add friendlier alternatives to `try-completion' for efficiently
> > obtaining a common string prefix or completion from a collection of
> > strings outside of the context of minibuffer completion.
> >
> > E.g. when you simply want to know the longest common prefix from a
> > list of strings without having to deal with any completion variables
> > or edge-case return values.
> >
> > Unlike `try-completion' which may return nil or t, the new functions
> > always return a string, simplifying their usage and (on account of
> > the "string-*" naming) making the functionality more discoverable
> > for programmers working with strings.
> >
> > The function `string-try-completion' provides the general case and
> > is just like `try-completion' except for always returning a string.
> 
> What is the purpose of having a separate function
> `string-try-completion'? I think it is confusing if the function
> respects the `completion-regexp-list' and `completion-ignore-case'
> dynamic variables, and if we end up with three functions
> `try-completion', `string-try-completion', and
> `completions-try-completion'.
> 
> Why not only provide a single function `string-expand-prefix' with
> additional keyword or optional arguments:
> 
> (cl-defun string-common-prefix (strings &key ignore-case regexps predicate))
> 
> The STRING or initial prefix argument seems redundant, since one can
> always use the empty string, and use `string-prefix-p' to check a
> desired prefix, or am I missing something?
> 
> (cl-defun string-common-prefix (strings &key prefix ignore-case regexps predicate))

Adding Stefan to the discussion.

Message #14 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>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 78719 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>, juri <at> linkov.net
Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and
 `string-try-completion'
Date: Mon, 09 Jun 2025 02:22:09 +1200

On 2025-06-09 00:21, Daniel Mendler wrote:
> What is the purpose of having a separate function
> `string-try-completion'?

The purpose was just to keep `string-common-prefix' as simple as
possible without people then needing to go back to `try-completion'
if they wanted the more complicated features.


> (cl-defun string-common-prefix (strings &key prefix ignore-case
> regexps predicate))

Yes, offhand that seems fine as well.

I don't think I have a preference.


-Phil

Message #17 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: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 78719 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>, juri <at> linkov.net
Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and
 `string-try-completion'
Date: Sun, 08 Jun 2025 16:34:30 +0200

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

> On 2025-06-09 00:21, Daniel Mendler wrote:
>> What is the purpose of having a separate function
>> `string-try-completion'?
>
> The purpose was just to keep `string-common-prefix' as simple as
> possible without people then needing to go back to `try-completion'
> if they wanted the more complicated features.

Okay, but for more features people can always fall back to
`try-completion'. What I find problematic are the dynamic variables
`completion-regexp-list' and `completion-ignore-case'. They should
rather be passed as arguments, such that the function is self-contained
and decoupled from the completion variables.

>> (cl-defun string-common-prefix (strings &key prefix ignore-case
>> regexps predicate))
>
> Yes, offhand that seems fine as well.
>
> I don't think I have a preference.

If this works for you, I think it is better to go with a single function
instead of adding multiple new variants of rarely used functions.

> -Phil

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>, Phil Sainty <psainty <at> orcon.net.nz>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "78719 <at> debbugs.gnu.org" <78719 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, "juri <at> linkov.net" <juri <at> linkov.net>
Subject: RE: [External] : Re: 30.1; [PATCH] Add functions
 `string-common-prefix' and `string-try-completion'
Date: Sun, 8 Jun 2025 23:30:59 +0000

> >> What is the purpose of having a separate function
> >> `string-try-completion'?
> >
> > The purpose was just to keep `string-common-prefix' as simple as
> > possible without people then needing to go back to `try-completion'
> > if they wanted the more complicated features.
> 
> Okay, but for more features people can always fall back to
> `try-completion'. What I find problematic are the dynamic variables
> `completion-regexp-list' and `completion-ignore-case'. They should
> rather be passed as arguments, such that the function is self-contained
> and decoupled from the completion variables.
> 
> >> (cl-defun string-common-prefix (strings &key prefix ignore-case
> >> regexps predicate))
> >
> > Yes, offhand that seems fine as well.
> >
> > I don't think I have a preference.
> 
> If this works for you, I think it is better to go with a single function
> instead of adding multiple new variants of rarely used functions.

This all sounds good to me.
___

FWIW (very minor) -

I agree it's good to have a function that always returns a
string, and "" is the right thing to return for that.  But
for testing purposes, i.e., if you want to do something
different when there's no common prefix, you have to test
using `string-empty-p'.  If nil were returned, you could
just test with `null'/`not'.

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

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

> I think it is confusing if the function respects the
> `completion-regexp-list' and `completion-ignore-case' dynamic
> variables,

Strong agreement, here.  It's arguably already a problem to use those
dynbound variables in `try-completion`, so it's even worse here for
a function which wants to be unrelated to completion.

> and if we end up with three functions
> `try-completion', `string-try-completion', and
> `completions-try-completion'.
>
> Why not only provide a single function `string-expand-prefix' with
> additional keyword or optional arguments:
>
> (cl-defun string-common-prefix (strings &key ignore-case regexps predicate))

The "try completion" part of the name sounds like it's motivated by the
historical accident of how we got to it, so if we want to help those
who're not familiar with (or thinking about) completion, a name like
`string-common-prefix` sounds better, indeed.

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.

> (cl-defun string-common-prefix (strings &key prefix ignore-case regexps predicate))

At this point, you might as well call `try-completion`.


        Stefan

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

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I think it is confusing if the function respects the
>> `completion-regexp-list' and `completion-ignore-case' dynamic
>> variables,
>
> Strong agreement, here.  It's arguably already a problem to use those
> dynbound variables in `try-completion`, so it's even worse here for
> a function which wants to be unrelated to completion.

Yes, exactly. I always wondered why these variables are dynamic, since I
think of them as additional arguments to `try-completion' and
`all-completions'. Historical reasons? Would it make sense to change
their calling convention, or do you feel that such a change would be too
intrusive? Probably it is not worth the effort. But in any case, we
should avoid the mistake for the new function in the string namespace.

>> and if we end up with three functions
>> `try-completion', `string-try-completion', and
>> `completions-try-completion'.
>>
>> Why not only provide a single function `string-expand-prefix' with
>> additional keyword or optional arguments:
>>
>> (cl-defun string-common-prefix (strings &key ignore-case regexps predicate))
>
> The "try completion" part of the name sounds like it's motivated by the
> historical accident of how we got to it, so if we want to help those
> who're not familiar with (or thinking about) completion, a name like
> `string-common-prefix` sounds better, indeed.

+1

> 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.

>         Stefan

Message #29 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: 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 21:30:04 +1200

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.

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.

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.

Is it ok to (eval-when-compile (require 'cl-lib)) in subr.el
in order to use cl-defun ?


-Phil

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
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: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix'
 and `string-try-completion'
Date: Tue, 10 Jun 2025 15:15:27 +0300

> Date: Tue, 10 Jun 2025 21:30:04 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78719 <at> debbugs.gnu.org,
>  eliz <at> gnu.org, drew.adams <at> oracle.com, juri <at> linkov.net
> 
> Is it ok to (eval-when-compile (require 'cl-lib)) in subr.el
> in order to use cl-defun ?

Can we please avoid that at all costs?

Why do we need cl-defun here, anyway?  How many arguments should these
functions have?

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

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

> Is it ok to (eval-when-compile (require 'cl-lib)) in subr.el
> in order to use cl-defun ?

No, it's not.  I mean, maybe there's a way to make it work, but if you
"just do it", bootstrap will break because `cl-lib` needs `subr.el`.
Much better to refrain from using `cl-defun`, or else move the
definition to a later file, like `simple.el` or `subr-x.el`.


        Stefan

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

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

> From: Phil Sainty <psainty <at> orcon.net.nz>
>> Is it ok to (eval-when-compile (require 'cl-lib)) in subr.el
>> in order to use cl-defun ?

Eli Zaretskii wrote:
> Can we please avoid that at all costs?

and Stefan Monnier wrote:
> No, it's not.  I mean, maybe there's a way to make it work, but if you
> "just do it", bootstrap will break because `cl-lib` needs `subr.el`.

Righto.  I figured the answers might well be along these lines.


> Much better to refrain from using `cl-defun`, or else move the
> definition to a later file, like `simple.el` or `subr-x.el`.

All good.


On 2025-06-11 00:15, Eli Zaretskii wrote:
> Why do we need cl-defun here, anyway?  How many arguments should these
> functions have?

There's one mandatory argument and four optional ones which
can be mixed and matched without any obvious priority sequence.
Daniel had used cl-defun when he suggested merging my original
two functions into one, and I thought that the use of keyword
args did seem like a nicer API than a regular function.

It could be a regular function, though; I don't think there
was anything *precluding* that.  I'd probably go with this
argument order if we do that:

(string-common-prefix COLLECTION &optional IGNORE-CASE STRING 
REGEXP-LIST PREDICATE)


-Phil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
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: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix'
 and `string-try-completion'
Date: Tue, 10 Jun 2025 18:32:03 +0300

> Date: Wed, 11 Jun 2025 01:51:29 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 78719 <at> debbugs.gnu.org,
>  eliz <at> gnu.org, drew.adams <at> oracle.com, juri <at> linkov.net
> 
> On 2025-06-11 00:15, Eli Zaretskii wrote:
> > Why do we need cl-defun here, anyway?  How many arguments should these
> > functions have?
> 
> There's one mandatory argument and four optional ones which
> can be mixed and matched without any obvious priority sequence.
> Daniel had used cl-defun when he suggested merging my original
> two functions into one, and I thought that the use of keyword
> args did seem like a nicer API than a regular function.
> 
> It could be a regular function, though; I don't think there
> was anything *precluding* that.  I'd probably go with this
> argument order if we do that:

Then let's have a regular function.  5 arguments is not too much, IMO.

> (string-common-prefix COLLECTION &optional IGNORE-CASE STRING 
> REGEXP-LIST PREDICATE)

I think STRING should come before IGNORE-CASE.  Otherwise, LGTM,
thanks.

Previous Next

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