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

Previous Next

Package: emacs;

Reported by: Phil Sainty <psainty <at> orcon.net.nz>

Date: Sun, 8 Jun 2025 12:05:01 UTC

Severity: normal

Tags: patch

Found in version 30.1

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 08 Jun 2025 12:05:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Phil Sainty <psainty <at> orcon.net.nz>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 08 Jun 2025 12:05:02 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 08 Jun 2025 12:23:01 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 08 Jun 2025 12:36:02 GMT) Full text and rfc822 format available.

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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 08 Jun 2025 14:23:03 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 08 Jun 2025 14:35:01 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 08 Jun 2025 23:32:02 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Mon, 09 Jun 2025 10:49:01 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Mon, 09 Jun 2025 10:57:02 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Tue, 10 Jun 2025 09:31:03 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Tue, 10 Jun 2025 09:49:04 GMT) Full text and rfc822 format available.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Tue, 10 Jun 2025 12:16:03 GMT) Full text and rfc822 format available.

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Tue, 10 Jun 2025 12:27:02 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Tue, 10 Jun 2025 13:52:02 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Tue, 10 Jun 2025 15:33:03 GMT) Full text and rfc822 format available.

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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 29 Jun 2025 03:46:02 GMT) Full text and rfc822 format available.

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

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: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix'
 and `string-try-completion'
Date: Sun, 29 Jun 2025 15:45:14 +1200
On 2025-06-11 03:32, Eli Zaretskii wrote:
>> (string-common-prefix COLLECTION &optional IGNORE-CASE STRING
>> REGEXP-LIST PREDICATE)
> 
> I think STRING should come before IGNORE-CASE.  Otherwise, LGTM,
> thanks.

I've pushed the revisions to scratch/string-common-prefix

After fetching, the revised changes will be:

git diff master...origin/scratch/string-common-prefix


My remaining niggle about having STRING before IGNORE-CASE is that
STRING, REGEXP-LIST, and PREDICATE all fall under the same category
of "filtering the COLLECTION prior to determining a common prefix",
so this order interrupts that logical grouping.

I've described the three filtering arguments together as a group in
the documentation, for better readability.  I don't mind switching
the order in the code to match if you change your mind about that;
otherwise I think this is ready to go, if you don't spot any issues.


-Phil





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 29 Jun 2025 06:07:02 GMT) Full text and rfc822 format available.

Message #50 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: Sun, 29 Jun 2025 09:05:55 +0300
> Date: Sun, 29 Jun 2025 15:45:14 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: monnier <at> iro.umontreal.ca, mail <at> daniel-mendler.de, 78719 <at> debbugs.gnu.org,
>  drew.adams <at> oracle.com, juri <at> linkov.net
> 
> On 2025-06-11 03:32, Eli Zaretskii wrote:
> >> (string-common-prefix COLLECTION &optional IGNORE-CASE STRING
> >> REGEXP-LIST PREDICATE)
> > 
> > I think STRING should come before IGNORE-CASE.  Otherwise, LGTM,
> > thanks.
> 
> I've pushed the revisions to scratch/string-common-prefix
> 
> After fetching, the revised changes will be:
> 
> git diff master...origin/scratch/string-common-prefix
> 
> 
> My remaining niggle about having STRING before IGNORE-CASE is that
> STRING, REGEXP-LIST, and PREDICATE all fall under the same category
> of "filtering the COLLECTION prior to determining a common prefix",
> so this order interrupts that logical grouping.
> 
> I've described the three filtering arguments together as a group in
> the documentation, for better readability.  I don't mind switching
> the order in the code to match if you change your mind about that;
> otherwise I think this is ready to go, if you don't spot any issues.

If you want to move STRING after IGNORE-CASE, you should rename it to
something like MIN-PREFIX.

Btw, the changes for the manual have the argument list wrong.

Also, this part:

  If COLLECTION contains exactly one string, return that string.

left me wondering whether this will happen even if that single string
doesn't satisfy the filtering criteria.

My single high-level gripe about this changeset is that it ended up to
be too tied up with completion.  AFAIU, the original intent was to
provide an API for finding the longest common prefix of a list of
strings.  With that concept in sight, STRING should have been a
mandatory argument (perhaps an empty string), and the fact that this
is based on the completion machinery should have been an
implementation detail.  The REGEXP-LIST and PREDICATE would not be
needed, either.  By contrast, what we have instead is a variant of
try-completion, and both the documentation and the API itself are
advertising the completion-based nature of the function too loudly to
my palate, starting from the argument named COLLECTION.  Why would we
need yet another variant of try-completion?

So maybe we should make this API simpler, so it could do its main job
without requiring such a large and complicated doc string, and leave
the rest to try-completion?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sun, 29 Jun 2025 07:50:03 GMT) Full text and rfc822 format available.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 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, 29 Jun 2025 09:48:59 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> So maybe we should make this API simpler, so it could do its main job
> without requiring such a large and complicated doc string, and leave
> the rest to try-completion?

+1 Yes, I had argued this before. The only additional argument should be
IGNORE-CASE.

(string-common-prefix COLLECTION &optional IGNORE-CASE)

All more complicated use cases could be left to `try-completion'.

> Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 12:06:04 GMT) Full text and rfc822 format available.

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

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: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix'
 and `string-try-completion'
Date: Sun, 06 Jul 2025 00:05:01 +1200
On 2025-06-29 18:05, Eli Zaretskii wrote:
> Btw, the changes for the manual have the argument list wrong.

Thanks; fixed.


> Also, this part:
> 
>   If COLLECTION contains exactly one string, return that string.
> 
> left me wondering whether this will happen even if that single string
> doesn't satisfy the filtering criteria.

Good point; I've clarified this.


> My single high-level gripe about this changeset is that it ended up
> to be too tied up with completion.  AFAIU, the original intent was
> to provide an API for finding the longest common prefix of a list of
> strings.  With that concept in sight, STRING should have been a
> mandatory argument (perhaps an empty string), and the fact that this
> is based on the completion machinery should have been an
> implementation detail.

I don't think STRING should be mandatory.  If you're wanting the
longest prefix from an unfiltered collection (which I think will be a
very common use-case for the function), it's unnecessarily awkward to
need to also pass an explicit empty string argument when it could be
left as an optional one.  Indeed, I'd say that not *needing* that
argument is one of the benefits of the new function, vs using
`try-completion' (which does require it).


> The REGEXP-LIST and PREDICATE would not be needed, either.  By
> contrast, what we have instead is a variant of try-completion, and
> both the documentation and the API itself are advertising the
> completion-based nature of the function too loudly to my palate,
> starting from the argument named COLLECTION.  Why would we need yet
> another variant of try-completion?

If `string-common-prefix' was not based on `try-completion' and we
needed to write all of the functionality from scratch, then I would
not be pushing to include and document the additional features.

It is based on `try-completion' though (for the good reason that
`try-completion' is already extremely efficient at performing this
task), and that has some ramifications for the new function:

1. It will support the same COLLECTION data types as `try-collection'.

2. All of the filtering features of `try-collection' are available.

I just see no reason to hide or suppress any of these things.  Each of
the filtering options may very well prove useful to users -- and they
are already implemented!  I don't know why we wouldn't provide access
to them.  It may be a somewhat advanced option feature set, but it's
not an /unreasonable/ feature set for this function to have -- each
filter would be useful in different circumstances, so it seems to me
like a perfectly useful thing to support, and it's so easy to do so.


> both the documentation and the API itself are advertising the
> completion-based nature of the function too loudly to my palate

We could safely drop the final sentence "This function is similar
to `try-completion', but always returns a string.", but I think the
previous paragraph should remain.

I feel the documentation should reflect the functionality, and the
functionality in this case is dictated by `try-completion', so I don't
see a way to avoid mentioning it.  I'd prefer the documentation to be
clear about what it does than to pretend that `string-common-prefix'
is an isolated function.


> So maybe we should make this API simpler, so it could do its main
> job without requiring such a large and complicated doc string, and
> leave the rest to try-completion?

Again, my personal feeling is that the filtering is reasonable, so
I'm in favour of keeping it.

I don't like "leave the rest to try-completion" because try-completion
is really awkward to use outside of a completion context.  The reasons
for adding the new function were:

1. Discoverability; `try-completion' is a very non-obvious name for
anyone working with strings rather than completion, whereas the
`string-common-prefix' name will be very easily found.

2. Ease of use: `try-completion' requires you to jump through hoops
in order to deal with its non-string return values, whereas the new
function deals with those edge cases to return what's useful for
working with strings.

If we force people to go back to `try-completion' to get the extra
functionality, we also force them to jump through those hoops, whereas
the new API is easy to use in all cases.

That said, my first implementation was almost exactly that -- one
simple function for the basic case which made almost no reference to
completion at all, and a second function which was /explicitly/ the
same as `try-completion' /except/ for taking care of the return-value
hoop-jumping.  With that approach we had what you've just suggested
minus the inconvenience.  No one liked the two-function approach,
though, so I merged the two functions into one.

I like the current version better, but going back to that first
implementation is certainly an option.

Another two-function alternative would be for the current
implementation to become the 'complex' version of the function,
and then have a simple version for common use.  Something like
`string-common-prefix' and `string-common-prefix-filtered'.


-Phil





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 12:36:02 GMT) Full text and rfc822 format available.

Message #59 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>, 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: Sat, 05 Jul 2025 14:35:06 +0200
Phil Sainty <psainty <at> orcon.net.nz> writes:

>> The REGEXP-LIST and PREDICATE would not be needed, either.  By
>> contrast, what we have instead is a variant of try-completion, and
>> both the documentation and the API itself are advertising the
>> completion-based nature of the function too loudly to my palate,
>> starting from the argument named COLLECTION.  Why would we need yet
>> another variant of try-completion?
>
> If `string-common-prefix' was not based on `try-completion' and we
> needed to write all of the functionality from scratch, then I would
> not be pushing to include and document the additional features.
>
> It is based on `try-completion' though (for the good reason that
> `try-completion' is already extremely efficient at performing this
> task), and that has some ramifications for the new function:
>
> 1. It will support the same COLLECTION data types as `try-collection'.
>
> 2. All of the filtering features of `try-collection' are available.
>
> I just see no reason to hide or suppress any of these things.  Each of
> the filtering options may very well prove useful to users -- and they
> are already implemented!  I don't know why we wouldn't provide access
> to them.  It may be a somewhat advanced option feature set, but it's
> not an /unreasonable/ feature set for this function to have -- each
> filter would be useful in different circumstances, so it seems to me
> like a perfectly useful thing to support, and it's so easy to do so.

Yes, it is very easy to expose all the details of the underlying
implementation. But why are we even adding this function then? If the
function only replicates everything already provided then there is no
value in adding it. Only changing the return type to string is not worth
the addition of a new function.

Good API design is also about curation. This means to make a good choice
about provided functionality and the arguments. The goal here was to
provide a simple function to compute the common prefix of a list of
strings (possibly respecting case sensitivity). The other arguments go
beyond that purpose.

Daniel




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 13:06:01 GMT) Full text and rfc822 format available.

Message #62 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 01:04:47 +1200
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.

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.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 13:16:02 GMT) Full text and rfc822 format available.

Message #65 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>, 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: Sat, 05 Jul 2025 15:15:17 +0200
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 13:38:03 GMT) Full text and rfc822 format available.

Message #68 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: Sat, 05 Jul 2025 16:36:50 +0300
> Date: Sun, 06 Jul 2025 00:05:01 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: monnier <at> iro.umontreal.ca, mail <at> daniel-mendler.de, 78719 <at> debbugs.gnu.org,
>  drew.adams <at> oracle.com, juri <at> linkov.net
> 
> > My single high-level gripe about this changeset is that it ended up
> > to be too tied up with completion.  AFAIU, the original intent was
> > to provide an API for finding the longest common prefix of a list of
> > strings.  With that concept in sight, STRING should have been a
> > mandatory argument (perhaps an empty string), and the fact that this
> > is based on the completion machinery should have been an
> > implementation detail.
> 
> I don't think STRING should be mandatory.  If you're wanting the
> longest prefix from an unfiltered collection (which I think will be a
> very common use-case for the function), it's unnecessarily awkward to
> need to also pass an explicit empty string argument when it could be
> left as an optional one.  Indeed, I'd say that not *needing* that
> argument is one of the benefits of the new function, vs using
> `try-completion' (which does require it).
> 
> 
> > The REGEXP-LIST and PREDICATE would not be needed, either.  By
> > contrast, what we have instead is a variant of try-completion, and
> > both the documentation and the API itself are advertising the
> > completion-based nature of the function too loudly to my palate,
> > starting from the argument named COLLECTION.  Why would we need yet
> > another variant of try-completion?
> 
> If `string-common-prefix' was not based on `try-completion' and we
> needed to write all of the functionality from scratch, then I would
> not be pushing to include and document the additional features.
> 
> It is based on `try-completion' though (for the good reason that
> `try-completion' is already extremely efficient at performing this
> task), and that has some ramifications for the new function:
> 
> 1. It will support the same COLLECTION data types as `try-collection'.
> 
> 2. All of the filtering features of `try-collection' are available.
> 
> I just see no reason to hide or suppress any of these things.

The reason is simplicity.  Right now, the API is intimidating, IMO.

> I feel the documentation should reflect the functionality, and the
> functionality in this case is dictated by `try-completion', so I don't
> see a way to avoid mentioning it.

Indeed, my main argument is about the API itself, not about the
documentation.  The documentation is complex because the API is
complex.

> > So maybe we should make this API simpler, so it could do its main
> > job without requiring such a large and complicated doc string, and
> > leave the rest to try-completion?
> 
> Again, my personal feeling is that the filtering is reasonable, so
> I'm in favour of keeping it.
> 
> 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
        "")))

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.  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?  Because the above "complexity" pales near the need
to understand the role and effects of each of the arguments.

> The reasons for adding the new function were:
> 
> 1. Discoverability; `try-completion' is a very non-obvious name for
> anyone working with strings rather than completion, whereas the
> `string-common-prefix' name will be very easily found.

This could be solved by a defalias.

> 2. Ease of use: `try-completion' requires you to jump through hoops
> in order to deal with its non-string return values, whereas the new
> function deals with those edge cases to return what's useful for
> working with strings.

I disagree that the above code is anywhere near "jumping through
hoops".  We could even show it in the manual if that is a serious
problem, and have this issue solved.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 14:05:02 GMT) Full text and rfc822 format available.

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 14:27:02 GMT) Full text and rfc822 format available.

Message #74 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: Sat, 05 Jul 2025 17:26:16 +0300
> Date: Sun, 06 Jul 2025 02:04:27 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca,
>  78719 <at> debbugs.gnu.org, drew.adams <at> oracle.com, juri <at> linkov.net
> 
> 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)
>            
>          ""))))
> 
> when it can simply be:
> 
>    (string-common-prefix collection nil nil regexp-list)

I don't find the above horrible at all.  And it would be even easier
to read if rewritten as follows:

   (let* ((completion-ignore-case nil)
          (prefix (try-completion (or string "") collection)))
     (cond
       ((stringp prefix)
         prefix)
       ((eq t prefix)
         string)
       (t "")))

Why is the above "horrible" or not easy to read and understand?

I did agree that a dedicated API for finding the common prefix of a
set of strings would be better, but it should be not harder to use
than the above.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 14:40:02 GMT) Full text and rfc822 format available.

Message #77 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>, 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: Sat, 05 Jul 2025 16:38:58 +0200
Phil Sainty <psainty <at> orcon.net.nz> writes:

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

Yes, but one should not forget that in order to use the function I have
to understand it and read its documentation. Therefore a simpler can be
a better starting point than a more complex function with multiple
optional arguments. Of course this only holds as long as the basic
function covers my use case. I will discover the function likely based
on its name `string-common-prefix' if I am looking prefix computation,
so there is a good chance that it will cover my use case. For more
complicated scenarios, the docstring should point to `try-completion'.

> 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 wonder how often you've written such code. I've written quite a bit of
completion-related code in recent years and I've rarely had this
problem, or the few additional lines here didn't matter in the greater
context.

It might be good to check if there are call-sites in the Emacs code base
which could be simplified by `string-common-prefix' in its simplest
incarnation and also with additional arguments. Call sites which are
about completion, where `try-completion' is more natural anyway, would
have to be excluded.

I suspect that there are quite a few call-sites where the simple variant
of the function will do. Furthermore I suspect that there will be almost
no sites where the complex variant would be needed, or would be a better
fit than `try-completion'. That's why I think it makes sense to offer
the prefix computation functionality at two levels of difficulty - the
simple form (`string-common-prefix' only with IGNORE-CASE) and the
complex form (the already existing `try-completion').

I think the reason why I am disagreeing with the additional arguments of
`string-common-prefix' is that the order of arguments does not feel
natural. I strongly disagree with the order

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

since it will hurt the reasonable use case where I want to compute a
prefix with case folding. I would be more comfortable with this:

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

Or with one of these:

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

A non-nil STRING is a special case, an optimization, which is also
covered by REGEXP-LIST by using a regexp with an anchor. It should not
come before IGNORE-CASE.

Daniel




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 14:47:02 GMT) Full text and rfc822 format available.

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

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: Re: 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 15:00:02 GMT) Full text and rfc822 format available.

Message #83 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:59:24 +1200
On 2025-07-06 02:38, Daniel Mendler wrote:
> A non-nil STRING is a special case, an optimization, which is also
> covered by REGEXP-LIST by using a regexp with an anchor. It should
> not come before IGNORE-CASE.

That was also my initial preference for the argument sequence so that
the filters were all together as a logical group, but Eli felt that it
was more useful to have STRING before IGNORE-CASE, so I wrote the code
with it that way around, and only grouped the filters in the docs.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 15:06:06 GMT) Full text and rfc822 format available.

Message #86 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>, 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: Sat, 05 Jul 2025 17:05:04 +0200
Phil Sainty <psainty <at> orcon.net.nz> writes:

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

Let me clarify - my viewpoint is that the following calling conventions
are acceptable:

(string-common-prefix LIST &optional IGNORE-CASE) ;; favored
(string-common-prefix LIST &optional IGNORE-CASE STRING REGEXP-LIST)
(string-common-prefix LIST &optional IGNORE-CASE REGEXP-LIST STRING)

This means I am not strongly opposed to the addition of the filter
arguments REGEXP-LIST and STRING, as long as they are given lower
priority.

I still favor (string-common-prefix LIST &optional IGNORE-CASE) since I
am not convinced that there are many call sites where the additional
arguments would be needed, and in the few cases, `try-completion' would
just do. But then I cannot say this with certainty. You've shown your
snippet and there it would be handy to have REGEXP-LIST. Also Emacs APIs
have the tendency to acquire arguments over time, so these arguments
could get added sooner or later anyway, by someone who hasn't read the
discussion, and then I don't really want to discuss this again. Also
extending APIs leads to additional effort for the Compat package, which
I maintain, so we could go directly with the four argument calling
convention.

Daniel




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 15:27:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, mail <at> daniel-mendler.de,
 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: Sat, 05 Jul 2025 11:26:15 -0400
>>    (let* ((completion-ignore-case nil)
>>           (completion-regexp-list regexp-list)
>>           (prefix (try-completion "" collection)))
>>      (if (stringp prefix)
>>          prefix
>>        (if (eq t prefix)
>>            
>>          ""))))

Side note.  I recently pushed yet another bug fix where we called
`(all/try)-completion` without binding `completion-regexp-list` and thus
ended up inheriting that regexp constraint from the context.

It's great that we can pass additional arguments via dynamic-binding,
but in the same sense as "it's great that we can patch things with
`advice-add`": it's better when we don't have to.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 15:29:02 GMT) Full text and rfc822 format available.

Message #92 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>, Eli Zaretskii <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: Sat, 05 Jul 2025 17:28:40 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>    (let* ((completion-ignore-case nil)
>>>           (completion-regexp-list regexp-list)
>>>           (prefix (try-completion "" collection)))
>>>      (if (stringp prefix)
>>>          prefix
>>>        (if (eq t prefix)
>>>            
>>>          ""))))
>
> Side note.  I recently pushed yet another bug fix where we called
> `(all/try)-completion` without binding `completion-regexp-list` and thus
> ended up inheriting that regexp constraint from the context.

Yes, a common problem.

> It's great that we can pass additional arguments via dynamic-binding,
> but in the same sense as "it's great that we can patch things with
> `advice-add`": it's better when we don't have to.

Your argument is so much between the lines that I fail to decipher it.
Which calling convention do you suggest we use?

>         Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78719; Package emacs. (Sat, 05 Jul 2025 15:30:02 GMT) Full text and rfc822 format available.

Message #95 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>, 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: Sat, 05 Jul 2025 17:29:12 +0200
Phil Sainty <psainty <at> orcon.net.nz> writes:

> On 2025-07-06 02:38, Daniel Mendler wrote:
>> A non-nil STRING is a special case, an optimization, which is also
>> covered by REGEXP-LIST by using a regexp with an anchor. It should
>> not come before IGNORE-CASE.
>
> That was also my initial preference for the argument sequence so that
> the filters were all together as a logical group, but Eli felt that it
> was more useful to have STRING before IGNORE-CASE, so I wrote the code
> with it that way around, and only grouped the filters in the docs.

Then we can maybe convince Eli that the following calling convention is
better, since the filtering arguments STRING and REGEXP-LIST are
deprioritized? The STRING and REGEXP-LIST arguments are
completion-related, while IGNORE-CASE is needed for basic
case-insensitive prefix computation.

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

Alternatively we could go with the simplest form and suggest to use
`try-completion' if additional filtering is needed.

(string-common-prefix LIST &optional IGNORE-CASE)

Daniel




This bug report was last modified today.

Previous Next


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