From unknown Thu Sep 18 18:05:46 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#78719 <78719@debbugs.gnu.org> To: bug#78719 <78719@debbugs.gnu.org> Subject: Status: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' Reply-To: bug#78719 <78719@debbugs.gnu.org> Date: Fri, 19 Sep 2025 01:05:46 +0000 retitle 78719 30.1; [PATCH] Add functions `string-common-prefix' and `strin= g-try-completion' reassign 78719 emacs submitter 78719 Phil Sainty severity 78719 normal tag 78719 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 08 08:04:23 2025 Received: (at submit) by debbugs.gnu.org; 8 Jun 2025 12:04:23 +0000 Received: from localhost ([127.0.0.1]:50880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOElC-00052p-Tl for submit@debbugs.gnu.org; Sun, 08 Jun 2025 08:04:23 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33312) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOEl8-00052T-0P for submit@debbugs.gnu.org; Sun, 08 Jun 2025 08:04:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOEl2-0008Av-9N for bug-gnu-emacs@gnu.org; Sun, 08 Jun 2025 08:04:12 -0400 Received: from smtp-4.orcon.net.nz ([60.234.4.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOEkx-0008V7-9Y; Sun, 08 Jun 2025 08:04:10 -0400 Received: from [10.253.37.70] (port=45756 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uOEkc-0007SS-IG; Mon, 09 Jun 2025 00:03:51 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Mon, 09 Jun 2025 00:03:46 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Jun 2025 00:03:46 +1200 From: Phil Sainty To: bug-gnu-emacs@gnu.org Subject: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' Message-ID: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- Received-SPF: pass client-ip=60.234.4.59; envelope-from=psainty@orcon.net.nz; helo=smtp-4.orcon.net.nz X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit Cc: Daniel Mendler , Eli Zaretskii , Drew Adams , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) 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)) From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 08 08:22:32 2025 Received: (at submit) by debbugs.gnu.org; 8 Jun 2025 12:22:32 +0000 Received: from localhost ([127.0.0.1]:50903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOF2l-0005u8-MV for submit@debbugs.gnu.org; Sun, 08 Jun 2025 08:22:32 -0400 Received: from lists.gnu.org ([2001:470:142::17]:43544) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOF2h-0005to-OB for submit@debbugs.gnu.org; Sun, 08 Jun 2025 08:22:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOF2X-0004IR-Ni for bug-gnu-emacs@gnu.org; Sun, 08 Jun 2025 08:22:18 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOF2V-00023j-Fe; Sun, 08 Jun 2025 08:22:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qAAdFSr5HQih4P9CawN0qZg7X92I7FgKf8oDn21Un28=; b=rOarHxZOOu7uIO7UwWTQZFCRtJ kd9YhkPfq0kLLsaCG7Delmi+tjbV6FWR1IV+Wlh5A2MIcF1h8zLqcT+PLUf4gHOnhlBBxAzLDqSpn A7m/trojyXj5gpOPlQyJ0hTdzvJdZV17k0dlRmA4hruXhV00AWpg6vUCtJswGHQ2O2ZA=; From: Daniel Mendler To: Phil Sainty Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> Date: Sun, 08 Jun 2025 14:21:52 +0200 Message-ID: <87wm9mh19b.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org, Eli Zaretskii , Drew Adams , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 08 08:35:20 2025 Received: (at submit) by debbugs.gnu.org; 8 Jun 2025 12:35:20 +0000 Received: from localhost ([127.0.0.1]:50917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOFFA-0006XO-4O for submit@debbugs.gnu.org; Sun, 08 Jun 2025 08:35:20 -0400 Received: from lists.gnu.org ([2001:470:142::17]:60840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOFF5-0006TG-BL for submit@debbugs.gnu.org; Sun, 08 Jun 2025 08:35:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOFEz-0006tP-CH for bug-gnu-emacs@gnu.org; Sun, 08 Jun 2025 08:35:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOFEx-0003Gq-2u; Sun, 08 Jun 2025 08:35:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9vHtzgpTdL+pPwNV0KgoyVkwb0vdXe/PiKmkL9VBgHc=; b=G1HrBFPR3Dr9 BMhx8Eb3OLcgH1An5TV/F+EUThoD7E0VTdEFyXqyqP++acRkq31+x1PP/MDIG41w3jQjJUrj81PgJ 9QQcLq/gR2R+pyJ1x14G2sPamW4cZEAABpJUuDLIbcHa4Iif+Jt0ovK4Qk3zMDKYraYW3iBbMaNxQ wQgObkX4/7DbFbIvhs0xUD2gHstCAUqS5aJTaatRENCZTJfG7yplXu09ep6NpV2MBFUqagpn9fr2Z mlWu+QLhZJKWzwcYZqq4pV911sUt9KP+0o8ZXG/ep42veYIBNX4mKlsJ6B40ee/oabPCOsrOoTQB0 EZ2wyz0/6V3B0W8wjnAICA==; Date: Sun, 08 Jun 2025 15:35:03 +0300 Message-Id: <8634cah0nc.fsf@gnu.org> From: Eli Zaretskii To: Daniel Mendler , Stefan Monnier In-Reply-To: <87wm9mh19b.fsf@daniel-mendler.de> (message from Daniel Mendler on Sun, 08 Jun 2025 14:21:52 +0200) Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit Cc: psainty@orcon.net.nz, bug-gnu-emacs@gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Daniel Mendler > Cc: bug-gnu-emacs@gnu.org, Eli Zaretskii , Drew Adams > , juri@linkov.net > Date: Sun, 08 Jun 2025 14:21:52 +0200 > > Phil Sainty 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 08 10:22:19 2025 Received: (at 78719) by debbugs.gnu.org; 8 Jun 2025 14:22:19 +0000 Received: from localhost ([127.0.0.1]:52475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOGug-0003kS-Qa for submit@debbugs.gnu.org; Sun, 08 Jun 2025 10:22:19 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:51779) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOGuc-0003kD-ML for 78719@debbugs.gnu.org; Sun, 08 Jun 2025 10:22:15 -0400 Received: from [10.253.37.70] (port=64343 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uOGuX-0003Hd-4N; Mon, 09 Jun 2025 02:22:09 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Mon, 09 Jun 2025 02:22:09 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Jun 2025 02:22:09 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87wm9mh19b.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , Stefan Monnier , 78719@debbugs.gnu.org, Drew Adams , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 08 10:34:45 2025 Received: (at 78719) by debbugs.gnu.org; 8 Jun 2025 14:34:45 +0000 Received: from localhost ([127.0.0.1]:52488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOH6j-0004IO-C2 for submit@debbugs.gnu.org; Sun, 08 Jun 2025 10:34:45 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:53959 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOH6d-0004I1-HZ for 78719@debbugs.gnu.org; Sun, 08 Jun 2025 10:34:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=83ChLY5px9Ccf8kTuSJJ6HGNMuctWurQMe1NUpiAXdg=; b=UmzKJ/fMJRAb6Yy9u2KH/q3+Mm CaaeyqbOZoc6DnzIVBnZFLu/uRMAnFdA/5dp3RXd0lezMIstYgFVg4Dttta2WYi1jSl1I6bZ3yviq EJRsAQDi9mfO8EponRVBXh7eVHtEwhpHZ9D3P2mAFjRkiWC2CFDaoDy0ezA5HRgqapKI=; From: Daniel Mendler To: Phil Sainty Subject: Re: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> Date: Sun, 08 Jun 2025 16:34:30 +0200 Message-ID: <87tt4qgv49.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , Stefan Monnier , 78719@debbugs.gnu.org, Drew Adams , juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 08 19:31:15 2025 Received: (at 78719) by debbugs.gnu.org; 8 Jun 2025 23:31:15 +0000 Received: from localhost ([127.0.0.1]:53236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOPTv-00041K-1O for submit@debbugs.gnu.org; Sun, 08 Jun 2025 19:31:15 -0400 Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:49402) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOPTr-00041A-6y for 78719@debbugs.gnu.org; Sun, 08 Jun 2025 19:31:12 -0400 Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 558Kdq7A020780; Sun, 8 Jun 2025 23:31:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2025-04-25; bh=4d28ABigaN8JIHTh3VLJMT/dmmjt3nZuULPdex3tWJ0=; b= PMmERbi8uozHxve1lbjqaLQrxvHx2R1wjBeipY7hXSEeJQLpc00pCyZoWGA0vKE1 +Whckgw7IdjV4aBx6R5zrU4gV0X3ZQQCnamvbqrtiwGK2rXjjs7IYXaHRDKZO9lD kUUaz/GwRq5cEES0mQJ6h9sJPYFjiMisfgl52aQ+WL/YRwZGmRPXRaWpvTlZ6R20 rzqfWLNNpubGSUTD80ott80JTlpM7iNCxVi19Xvg/dlznHKwP0POOVkmbnX7OELW i8VgzS6kXvV6vmB5ce7cs5F5Uckmi8FdsGlN4mc/ZXHHFf4JcjXzEqYpG57jEFMN GbYJPFk1bZYWeKKBbLhIbA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 474c1498yd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 08 Jun 2025 23:31:04 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 558Mcu8H003279; Sun, 8 Jun 2025 23:31:03 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10on2052.outbound.protection.outlook.com [40.107.94.52]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 474bv6um69-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 08 Jun 2025 23:31:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MmCuiMdt6BqHgp3hocvTghS8Fxg4YOK9Bsv8RqjD2eM4rNw5IK09LQQI3Ol180FMjm75U0zhXzCAYw/Jim2GTTJLpBsBKS0IXJadPmAxi2KzJ4PwX61/xDJNl4pRIzl5qv+wxEn2Hl4Ky3J5rTpVP5criXefgHGuygMlHcm1uf6yAEiARTET1Ti8uqEHjlti59mhUI47D71Po7ENkEPFbFQRG9kedM65XZM3bl427T+QgNffqwTAbFUAr/VRbVhAUifk3wCxrGDYgqyiOqGFRly7mmSGicUzQgquXlAa59iO1yjWViaUJobGY10it/xWYDRr2QTZ5LMseJ68ffp8+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4d28ABigaN8JIHTh3VLJMT/dmmjt3nZuULPdex3tWJ0=; b=tBKyKz3hEwoUtyGVh2v9VjvUdcsj77sg0V1A3yXgkOq3qNmiQehiB9j1DUX6hoZkRZzuZoorz2uCbayln2jXJPc4E7yK0zq5jI1diC+Jxjo1Yq5JLTeJGgt6U4miypAcRvUcA6vwLYJkLQhFiPxz5V301LANP5ivb9L0IGTC4YxNlZjDpwyYFWE6k88B4Lpn17YqoXHI7Njpc4ePA4kgCByO+63L0g4nBaSzP1DKdPdSt/RVBS+VabdkMXEjRi1AI2RffdLB5I38TF2/mwvU0nPx259w0zXO9r5QhSTk9Up2SmVqxnAEdxpAkaZvu0RfH3Y8s8B7ZFy0pHemKyut0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4d28ABigaN8JIHTh3VLJMT/dmmjt3nZuULPdex3tWJ0=; b=RHnBgADPzYyS2TZnXeGM3X73xUUxkgR7p8F2IVJvCZNTEgeuHGolDlv/BzSwEcEe6csJUMY2gWonj9O+QmhAOLH3myAA2ypk0L3UvWB/ABC9fg4ftypInDQ6dE2KTguX3IZ2ko2rQysoSI95NzqwfI1KWrcVqWjAMar47y+FJmY= Received: from DS7PR10MB5232.namprd10.prod.outlook.com (2603:10b6:5:3aa::24) by PH7PR10MB6484.namprd10.prod.outlook.com (2603:10b6:510:1ef::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8813.29; Sun, 8 Jun 2025 23:31:00 +0000 Received: from DS7PR10MB5232.namprd10.prod.outlook.com ([fe80::8303:658f:14f8:2324]) by DS7PR10MB5232.namprd10.prod.outlook.com ([fe80::8303:658f:14f8:2324%7]) with mapi id 15.20.8813.021; Sun, 8 Jun 2025 23:30:59 +0000 From: Drew Adams To: Daniel Mendler , Phil Sainty Subject: RE: [External] : Re: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' Thread-Topic: [External] : Re: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' Thread-Index: AQHb2IJ7B5u4k6Pv4UOWoEUnFbgKBLP55ZBw Date: Sun, 8 Jun 2025 23:30:59 +0000 Message-ID: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87tt4qgv49.fsf@daniel-mendler.de> In-Reply-To: <87tt4qgv49.fsf@daniel-mendler.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR10MB5232:EE_|PH7PR10MB6484:EE_ x-ms-office365-filtering-correlation-id: 59feacb6-6229-48cc-c288-08dda6e486ad x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?us-ascii?Q?WsiUT6eNj1A4DAvnc10IdpesfFQe2WUsYQNDcMXBvRUjiH38WkJMynuBttTy?= =?us-ascii?Q?1hTsfRRO0XqxV5T94vEyFFMxAroM0Fyp7/cqX5KgRmVuf9euO1LuLO3yYcdq?= =?us-ascii?Q?U6HU7DYymp3rxIYyexTV+2Bcr3f3dl3sAx/W0zTWXSdlj5ShGy6V+7Fr4zAA?= =?us-ascii?Q?9LMoGS7gp5TGs+L/usnmDIDyHi0Z5eWhMCsEhS+HGSo3/uUjXqMsVk8XMRAb?= =?us-ascii?Q?mfnXObPxQi5++S0WSAWSy6AbQVw0GRUApP9yUx/2yh0q/jiU/SkSgaM3XcMb?= =?us-ascii?Q?D2lFLG4kAlkoMD1HRbUezUi1TbnHkRgehFuFMZFjdIELLPvKOaOhp2RXXxDV?= =?us-ascii?Q?XPU+q3+h/2w+VesruoP3p+Hb7+2Bcsw2Ef1bbFFXAv9vE6Y5eRHZ8/npa/FG?= =?us-ascii?Q?rbkg6h4bitbex82P8atD5d5w6LutQk9LKoEy7HekIA5HKpb8avFXYXzWwZTJ?= =?us-ascii?Q?EvWUmczL3M8VVHG6/3uMUHxYipy17twJy+wP65bCK8CV/dkBM723vTB/U/4P?= =?us-ascii?Q?SoihZ4YbB4HmaPEpiJxlzLMTGfHa5bJ2hgxGm/0uls5fEOpF1XJ5rqrFenwq?= =?us-ascii?Q?vFS/u4m2+b4m6/t6ebUEEIWb5cNrDDxjHWg44VxllHTQy9EFSl28fBrofEce?= =?us-ascii?Q?96FP0/wRSKMnhKt81UyWbN2ItVX01oU/DoNT16JrZxsudaT2MG+u6EHhTsek?= =?us-ascii?Q?ru6l+Lw/lXn+WPgZP8OehhJWce/9L5sWOwHGQsBrStQebXdO/1PjQs4qHZGr?= =?us-ascii?Q?B2PpAjZeSmg9txEW67LvHBsWczI/U++fjrkBO4KutrlWqiRs4FoM3f4JTOlq?= =?us-ascii?Q?hty2vUyOpt9I1g9gU5MoQtd+ff7QOzRXK6dltApcyV00I2m3xxgQUt1H1DRe?= =?us-ascii?Q?0LpPvsYPsGEJnkitF/8ac/fH7QDgyw1AkhLMn6XLvsrbnF127qx+3inWkwuT?= =?us-ascii?Q?XzqtDVdK/CIRS4HxvoJHOwNZFkwaRkyN02dby2/9xvVMswFonVh9lH6xaZuq?= =?us-ascii?Q?dThQ+DMIv/V8CKZ6VWC7P6vZ9Nq+CTNjQsepdOzv8QuuVl09NrvHEXZcDuYz?= =?us-ascii?Q?MsrpCQp94OJKm3/eiRvxkthEDTv0fa+YmL6jXUizYyPsLJdcO9v/n45yGcd3?= =?us-ascii?Q?Pk0Eb6eOZdweyyEzDXpYB+sfinDnwvO/Eg/IZjW3S8lOtIlLwgM/eiIzgY9H?= =?us-ascii?Q?L9RefTyDSZSs5NXf3H4TJwL+9e4301LuxZHOAtif5pvgkCq1tvkMDMC1mDng?= =?us-ascii?Q?GqVCSLI7IyWul1snu0yluZQGJeN1pCaI+U0CBJJ67Ke/EwSaI3vn7/Nau7nL?= =?us-ascii?Q?nG22cAxDOJflBAZWtrtpinWRH6Fm/82XCQmAEcdsj7NbGuOjnJi2Hu9xR5Ij?= =?us-ascii?Q?gRE5+FT0g8J/eLkK6fF5q8O7QlZosWRlTJfEt9XMumakeSYxndMGN3obIP+e?= =?us-ascii?Q?LVpR82TxolgCIHqsMGKhkteTIXu3RWeWKirBZu8A5G8F6DMw9FDd6K1M0hVr?= =?us-ascii?Q?3AfeyT/OqDgsTNI=3D?= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR10MB5232.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?WRQhvOQs595IRDJoYJZHFdE+ty6ay6a2dZOw6yGfMnvCHpT8nlzG192cF5kV?= =?us-ascii?Q?w2rtXuk8Kqj94Y29uk3R4n4VQDtb+fDQrcHV6C2GlPRZjN/XbhS8mj56czFR?= =?us-ascii?Q?rRIUZvyoz9Fc+rjSbpkIiP4+az5j30rVTgos9eoDwNbADc1VsFCOm64uaZWE?= =?us-ascii?Q?iKZF1iSMV52+R/o40uiNkfzeAqbvOAmTx7g6d/55OBKI/o3M0KZ0ZukTG15X?= =?us-ascii?Q?VU7MAomsandkwn6FDo1TpDk1JWGzl8a8QtO3w1IXnmyYwqfcVomYJL9DtQbG?= =?us-ascii?Q?w/436TqxW8tk6L977cK3kcsEf5ycQmxLqEGXgVYq+Tz7t0Ac6TwWtHzfr+Fh?= =?us-ascii?Q?tjisUQ1Oqx8evy/9oCtkLa3tkyEHASFI6Ci2+8+/7JPx1XsvNJICuy9i2Dzw?= =?us-ascii?Q?bAr/hsxAmHaKV110hD6//IuZI67+zMwZtQcVkoLk++7Fj/v646/NQ7kpkDB0?= =?us-ascii?Q?d1/C37jjQNYG0Qh1wzTzd/UXD723A7T8czsFIi72/beH/wWIXQhwujjRj4EM?= =?us-ascii?Q?DkOGcslE1cA0Qoq3CLwMmez5ncmuN7Zt1ebCKh28/WHi+5QWXs32HmhPi7ew?= =?us-ascii?Q?U43wTaw4kx6XnWNenmlPBChRzHQ/iJe0gc4pUBZcMK/Vx0K1YePLkAeLvQ6+?= =?us-ascii?Q?dYqF7UQZRHU9GMgDVm3soutZ7F/Ba0noJbt9b2gUJPx96L3S3As0TU0oHWbC?= =?us-ascii?Q?boeFqhDUC3pzT43fyp9yYSaY1+QyC3Xzt8hWvdq1qJYCAcf8fqSZ8UbYXVRa?= =?us-ascii?Q?N6HBesVGhwWGJI2d4DVIhwd/QHXPvop4OlvJLIU17nASp/eIt6VfsxRM0GMo?= =?us-ascii?Q?+/C4v+6LA0JHZXbP1EZVp/otNw2v2PtUYnjNKp32yafmpgyJ5wRVyEufRwjB?= =?us-ascii?Q?47jOh3gYpJHHXN1Ds7qHyEFrk7u8DGxK1S390VU+sQMYLeFrNEqKyKsbKHK0?= =?us-ascii?Q?1l1m9oNJLmpJtGGlZ3dle2/v4al0rUhEDS/825xdgsPUB1gY4NDUet/q96zW?= =?us-ascii?Q?+j1LC01gcOeNrBWUxk0rO5EyMxCceLn2Owq0tLvmLJ9/0fkjQyJCfFuICQBK?= =?us-ascii?Q?wNf3PNMjfQfPILwM/b8ZHNSzzYdYmXVsR5ikqTcO3sbJXmCr3mSeb/7DwSVu?= =?us-ascii?Q?X21nTuwFezkKRxMM2/rH2FSeQpZ6vTwzFi8d2F+Ekfip5hsZYzoywVQ9HJH5?= =?us-ascii?Q?a50vcB0Cmbw+4iPextZ2wsBlaBnjHSYbLnaOmekQq+U/UuSBYrpwEORMSoKj?= =?us-ascii?Q?UmwnzBbI1tdBcB78Qu6ZT4gEfe8v06TN8JTNwyOrtf/50SpQreSN+zBCNK/N?= =?us-ascii?Q?BMmip6PTjR5a2IIrvNgi6JKlxb9LERYx9HBiD919SqrhgvKsdgJ1zd4psy7V?= =?us-ascii?Q?e3WlNcueEhh19H3b4uPjorybYcMotizaSSBrraj+9ccojePaYC2ClANAoV+x?= =?us-ascii?Q?ofJB0nr/kLThmEYhLsZA9jOgC9x3S7I/eKmT0rT0j2BNLG4dmj2abNhom3OH?= =?us-ascii?Q?9BRZqgEGZD0UF3t6wOsIWVAN1w8T9dMxMHMGavP/at2+LIWeUJOfgJVZ+JcW?= =?us-ascii?Q?gzEzCjQzm2xNl47JybddciGRsjl+QAWtWk/HcOxb?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: tSPZVAJKgDRKtCGUNVZ6GGMSwWoYur261TBNlC4aK/cevgypgjgZlnv8DGhqseNuwPhDpASsHY7rPmjBv55/ScW0NkMu/oT5Eq9ZSKbrgTz5x+b3AEonNA+leUMETq4SJeoWZJYKQNwfEaB09HU3YEYnRMr8V2V1d5I77HdWQKeMIneokaYGRDkXzJIraCcQQ63p7NqOXV0c2GA4Uaqgu5lcMYD6fcYY7DrGqsPDFz7W0gZHFuW4jJE4f93WJrlSPBPfMuhb2YmKT/kGuC25STpJjmUE8OP3bY9cHJHuF9yF+a7VBH40SXI49I59o/Xx6xW6SdUOfE1n6R765+AkUxxiQNEiOxoIwmNE5nUweq4qfymc0Q97VDAyl+fPG53HMb7iGxu9KrDYiXZwnh460UKbA6WR6awm1eH8R5fCWVVQCqqeSJ5sv2vRBjs1Fo3iGTK1m/DdQNigAUXRlocCe/wA220qELrIQnrlc/282AbYUhzmyauP/M/nM9Xoz0JrUqWn8WvbRVPyzhUIPE7mCXIpZie7A+131RtI2KJjqpZQoQgI5yRRpqm40ogk2Wgw96XP0uzHEi1J+67cVr/H17O1Hz0ew2G9Om7x87oSc5k= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB5232.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59feacb6-6229-48cc-c288-08dda6e486ad X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2025 23:30:59.8223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B8ZZPy7oAlemZm0BrksfIc/muB9ujJKLJDL6q/o7lDaGNN0QCLp9Ot3FjNMdFicfshn8eGv5FRomqOZ45rZhjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6484 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-08_05,2025-06-05_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 phishscore=0 spamscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506080192 X-Proofpoint-GUID: _YBvUPvb16BOQ1pyMPf6CHJWdGdft8Fa X-Authority-Analysis: v=2.4 cv=GcEXnRXL c=1 sm=1 tr=0 ts=68461d38 b=1 cx=c_pps a=e1sVV491RgrpLwSTMOnk8w==:117 a=e1sVV491RgrpLwSTMOnk8w==:17 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=6IFa9wvqVegA:10 a=GoEa3M9JfhUA:10 a=W8vGuGGEViEqWTaiTFIA:9 a=CjuIK1q_8ugA:10 cc=ntf awl=host:14714 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjA4MDE5MiBTYWx0ZWRfX05BCOGgNI/9R cxBIBLBSmPSECHYP3JazG6XkxUYl3NPBTYEBzKxLdfoR1/6IBCisxCo48H8QyUQw39u5tq4wukd HAOiBDY8Drvl/7KQx9nvJZ8qjY9tbNpYvLUNzJeDS75nvpxDUEo8FjFgLVTYg+mqsgj9cBmYgXO 6kiDQEPCwzxt0DhK781ZsHx/bLs0RGCT8rdYpp6fuk55cPMDn+ks+uSdnkZ3dEoPSEBgAkjnrw1 YuAqN63AHq1XkOKWhkhCZ+NzirhaTRL/jjo6FvVTDs261eFRU1HYRDAEfgB2BFpDxzmtZQGqW2k nK8sH2tBVNxMifJCHfGbqhzgmgYN8oMgHbmuV60y0LxFnL4Jng6jArqt0YEmYsmWV1c10jTuEa1 s1jyJL0f06//yu0Z6dRFGcGdbLccwUlpxfdqivqi8ap4VFMYpk0jECEnoWP7N+MUil4B63W9 X-Proofpoint-ORIG-GUID: _YBvUPvb16BOQ1pyMPf6CHJWdGdft8Fa X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , "78719@debbugs.gnu.org" <78719@debbugs.gnu.org>, Stefan Monnier , "juri@linkov.net" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) > >> 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. >=20 > 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. >=20 > >> (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. >=20 > 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'. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 09 06:48:29 2025 Received: (at 78719) by debbugs.gnu.org; 9 Jun 2025 10:48:29 +0000 Received: from localhost ([127.0.0.1]:54038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOa3J-0000tC-8p for submit@debbugs.gnu.org; Mon, 09 Jun 2025 06:48:29 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12727) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOa3I-0000sx-5Y for 78719@debbugs.gnu.org; Mon, 09 Jun 2025 06:48:28 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ED60D440924; Mon, 9 Jun 2025 06:48:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749466096; bh=udbVkiML/8maAJXdk2n7/r6MwIKPA/wY6T6JccBXp+g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R7et49atOv5dziIc6UdC4CUSrPKownEqKySN1+8dq6hjMmIIVyhl5wjbDeMEiNWOB wYTB0SxbQkBJKuny8SX99iVJixpZJsvcOQR2QJ7ZX2rTdU60jW397AV/pqZAcJHMJv H52N9qlr+ZiolJkrFUCABEx92lswpMWgcSGF3VFYhInixxBlbJBXBKVpNfPHXQy5Q5 qImWRQpKomDqVVDw5Yw4ohQKqcelB2l8q4Xv2cYdP74JRS+NnEXd7aB5StVsj+eaED 6KFcWss4+6FXRenLTS388nyMsPRTnvRdPZxpFchhmgmpve657q3JDBjqwcIXsiZ+0y usHZWUnfBoWvA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 71E414400EC; Mon, 9 Jun 2025 06:48:16 -0400 (EDT) Received: from asado (unknown [130.159.222.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B8A9120099; Mon, 9 Jun 2025 06:48:14 -0400 (EDT) From: Stefan Monnier To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87wm9mh19b.fsf@daniel-mendler.de> Message-ID: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> Date: Mon, 09 Jun 2025 06:48:11 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: Phil Sainty , eliz@gnu.org, 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 09 06:56:53 2025 Received: (at 78719) by debbugs.gnu.org; 9 Jun 2025 10:56:53 +0000 Received: from localhost ([127.0.0.1]:54064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOaBR-0001Ha-0U for submit@debbugs.gnu.org; Mon, 09 Jun 2025 06:56:53 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:33957 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOaBP-0001HO-I2 for 78719@debbugs.gnu.org; Mon, 09 Jun 2025 06:56:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yk4FPBFxUDoaXmeekgiF5A1JvEV3/xE1GZ5gr+IyQmY=; b=G6MJKP8EoWjwdzGpAYujbHD3zz Lw34xdbE67fj73mzREsvgh9hUPS+EgDSEfet+LT+ZW5VZ4v/9Tv8WxaAmAi29pQmnxtE5WsLuAx8i 82I5q9RFyUljCr+fwAgfJCFXLwQvD4W6yJXp9k3tSKYghzejPPA/rPH4fGJ8hKVqrHM4=; From: Daniel Mendler To: Stefan Monnier Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> Date: Mon, 09 Jun 2025 12:56:42 +0200 Message-ID: <87ldq141zp.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Phil Sainty , eliz@gnu.org, 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Stefan Monnier 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 10 05:30:26 2025 Received: (at 78719) by debbugs.gnu.org; 10 Jun 2025 09:30:27 +0000 Received: from localhost ([127.0.0.1]:34501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOvJG-00009M-M9 for submit@debbugs.gnu.org; Tue, 10 Jun 2025 05:30:26 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]:47385) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOvJA-000076-Cp for 78719@debbugs.gnu.org; Tue, 10 Jun 2025 05:30:19 -0400 Received: from [10.253.37.70] (port=39560 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uOvIy-0004aU-SX; Tue, 10 Jun 2025 21:30:05 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Tue, 10 Jun 2025 21:30:04 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 10 Jun 2025 21:30:04 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87ldq141zp.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: eliz@gnu.org, juri@linkov.net, Stefan Monnier , drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 2025-06-09 22:56, Daniel Mendler wrote: > Stefan Monnier 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 10 05:48:30 2025 Received: (at 78719) by debbugs.gnu.org; 10 Jun 2025 09:48:30 +0000 Received: from localhost ([127.0.0.1]:34528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOval-0002za-Rh for submit@debbugs.gnu.org; Tue, 10 Jun 2025 05:48:29 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:51971 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOvai-0002y2-CT for 78719@debbugs.gnu.org; Tue, 10 Jun 2025 05:48:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YAAFC9wJLevEOSo74TXmv1u/QINdb0L+CpqqYvufbiU=; b=it6P5Rt6SwZmwKsCPGeQty//VY OEyD/xrnMKPkvxAOiMpx7ComMFtYjtT5d0KLY8uH/9dWPLW+TuftsTdstDPuqh4MEkyTCNHR4s1rZ ol4C5geRJW1WgQ/J4eMRskCAApcPQuMetBL5TtREHsY/zkk0zAY0kNFbOYYQ0dGSiwqg=; From: Daniel Mendler To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> Date: Tue, 10 Jun 2025 11:48:13 +0200 Message-ID: <877c1kx6zm.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: eliz@gnu.org, juri@linkov.net, Stefan Monnier , drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty writes: > On 2025-06-09 22:56, Daniel Mendler wrote: > >> Stefan Monnier 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 10 08:15:54 2025 Received: (at 78719) by debbugs.gnu.org; 10 Jun 2025 12:15:54 +0000 Received: from localhost ([127.0.0.1]:36646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOxtS-0003Je-0j for submit@debbugs.gnu.org; Tue, 10 Jun 2025 08:15:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44222) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOxtO-0003JM-OK for 78719@debbugs.gnu.org; Tue, 10 Jun 2025 08:15:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uOxtF-0005h7-75; Tue, 10 Jun 2025 08:15:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=vgatRmCuWeoVnaG4H+UpKtzL2QEeaOw9slfm67On9HA=; b=OQALWSNexMhb NVjLRozc4Nh1ZrdWKCgEqyQeAenlwlaBgMJnCOrFyoIeVkva1jLYB11Q3+HMt8ZGhYhtclGyy4NTe aQl8SqBe+gnQoBouMCJTRAMYdNGnyHxLDtL/t6n70SJp656ykJUFUw5W1UOhffIC9AU3Y6685cObB QaYEmcfDUy3hNdkUU6y5Ry6ESp2nMMLkuelnWS+QcP8nKVul6er5INFc5vWw1UlAyPwkNPz27oGho BzCXQSYpLAdbMywlCpRp7gW+Z7IdybgMQsqYC7PAQwYl/UbBaR0lIoey8LTfv7kKwNUsKciMCvfcl l4YS4zJIOkMY0DrEdq6AeQ==; Date: Tue, 10 Jun 2025 15:15:27 +0300 Message-Id: <86bjqvg5cw.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: (message from Phil Sainty on Tue, 10 Jun 2025 21:30:04 +1200) Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 10 Jun 2025 21:30:04 +1200 > From: Phil Sainty > Cc: Stefan Monnier , 78719@debbugs.gnu.org, > eliz@gnu.org, drew.adams@oracle.com, juri@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? From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 10 08:26:17 2025 Received: (at 78719) by debbugs.gnu.org; 10 Jun 2025 12:26:17 +0000 Received: from localhost ([127.0.0.1]:36856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOy3V-00045N-7q for submit@debbugs.gnu.org; Tue, 10 Jun 2025 08:26:17 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32360) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOy3T-00044x-3w for 78719@debbugs.gnu.org; Tue, 10 Jun 2025 08:26:15 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0F690808F6; Tue, 10 Jun 2025 08:26:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749558368; bh=jwEtI8s79TNMU53Ze3r0maeGny1GK6GYx10hRly5+vk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PLFhUERPoalZS5qUPBv27fU/Nf+a+fRjqoyO7YQ2cphZTtoA4YzReFwMWzFrQOm+c QaJOJF53RU8B3vC+N7Myz9PGhkpJuXeAFq0tYXk73cKsPZeQ2lq57gXzXOzGdyywfM lFrnQs28N8NxIM0bTo5rTfg1+N+iNO8RdbWGSrM0nNZbvBhty46pDwlfJV54nc1FW7 bUt1TKoQte171cSOPVBlrSnmD10iydH1LI8IuPMrCheiZGSwxlTnKs3pux8+hxbbR6 aw73iJli/Q7iUvdmOVDShWRgC2Z/jVsUBoq0T8DeCOc3pYq/XEH9spXl3u8EUOrtlD 5+ufTsb1iCKlw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4EF9480038; Tue, 10 Jun 2025 08:26:08 -0400 (EDT) Received: from asado (unknown [130.159.222.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6D3E51203D6; Tue, 10 Jun 2025 08:26:06 -0400 (EDT) From: Stefan Monnier To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: Message-ID: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> Date: Tue, 10 Jun 2025 08:26:03 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.174 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: Daniel Mendler , eliz@gnu.org, 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 10 09:51:49 2025 Received: (at 78719) by debbugs.gnu.org; 10 Jun 2025 13:51:49 +0000 Received: from localhost ([127.0.0.1]:37763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOzOG-0004mp-Ob for submit@debbugs.gnu.org; Tue, 10 Jun 2025 09:51:49 -0400 Received: from smtp-3.orcon.net.nz ([60.234.4.44]:36425) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOzO7-0004kv-M8 for 78719@debbugs.gnu.org; Tue, 10 Jun 2025 09:51:41 -0400 Received: from [10.253.37.70] (port=20996 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uOzNy-0005dq-0p; Wed, 11 Jun 2025 01:51:30 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Wed, 11 Jun 2025 01:51:29 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Jun 2025 01:51:29 +1200 From: Phil Sainty To: Stefan Monnier Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> Message-ID: <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Daniel Mendler , eliz@gnu.org, 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Phil Sainty >> 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 10 11:32:22 2025 Received: (at 78719) by debbugs.gnu.org; 10 Jun 2025 15:32:22 +0000 Received: from localhost ([127.0.0.1]:39194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP0xY-0006GF-Q7 for submit@debbugs.gnu.org; Tue, 10 Jun 2025 11:32:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57122) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP0xT-0006E9-3k for 78719@debbugs.gnu.org; Tue, 10 Jun 2025 11:32:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uP0xK-0005DJ-De; Tue, 10 Jun 2025 11:32:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3FPpXOS3r3y/We+Y7M6mFqCvuvF5s7s9OzcB93ZLnfU=; b=Sk1MuatAJZhY uG249DrbyFsTKj797gCKe9iSeMphVPuDyOtgn4uqkKhf5JbGAOnot5/tjuWQWzrdHvbPipleZl/8a rqsSdtRSsITNJuETfpL8fF66XQ/51nKk7+N64ancKqmb0eqX3+BgGyMHDE2pnLtF3rBCAswglzHzd ZxeuE952xnkkPCLXpCYdVCmvZaqZW48s4nDaeEMX7G0nHEb9uC2/RP88n0V9pP8ijegB8VqEtG0Ii +waYF3LdAFFfRsJR64Zfwp/ewWY2OAHjADg76hqZfuiEAJNXu+aF+nhVrDDeK4Vhd9kwSuU4kqoy5 Ft7c52EHf2xDXQCuOCMUmQ==; Date: Tue, 10 Jun 2025 18:32:03 +0300 Message-Id: <864iwnfw98.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> (message from Phil Sainty on Wed, 11 Jun 2025 01:51:29 +1200) Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 11 Jun 2025 01:51:29 +1200 > From: Phil Sainty > Cc: Daniel Mendler , 78719@debbugs.gnu.org, > eliz@gnu.org, drew.adams@oracle.com, juri@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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 28 23:45:32 2025 Received: (at 78719) by debbugs.gnu.org; 29 Jun 2025 03:45:33 +0000 Received: from localhost ([127.0.0.1]:53713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uViyx-00024a-5W for submit@debbugs.gnu.org; Sat, 28 Jun 2025 23:45:32 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:47149) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uViyt-00022F-9J for 78719@debbugs.gnu.org; Sat, 28 Jun 2025 23:45:28 -0400 Received: from [10.253.37.70] (port=56548 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uViyg-0006ir-8B; Sun, 29 Jun 2025 15:45:14 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sun, 29 Jun 2025 15:45:14 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 29 Jun 2025 15:45:14 +1200 From: Phil Sainty To: Eli Zaretskii Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <864iwnfw98.fsf@gnu.org> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> Message-ID: <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 29 02:06:15 2025 Received: (at 78719) by debbugs.gnu.org; 29 Jun 2025 06:06:15 +0000 Received: from localhost ([127.0.0.1]:54197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVlB5-0002bE-Lk for submit@debbugs.gnu.org; Sun, 29 Jun 2025 02:06:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49324) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVlB1-0002ZL-AO for 78719@debbugs.gnu.org; Sun, 29 Jun 2025 02:06:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uVlAs-0001A3-5n; Sun, 29 Jun 2025 02:05:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=kCxJBjpomdJQ7rQ6Nymghzd5oCJ2LHgSRRrrvRF64vQ=; b=K9X542PrxIBm n1c1TQCPSLcgn64wqUmWxQ43cnwGJYKSM+zfrM4bOCKcekAY1o+SlV0GzVuXokxdPtHczUoMz1GAa sQJzTGNJM7qb9GZaOvfyFP/R+FFQv6dZ9QDdhNiulJJPduIbw9le/RRZcZ+iigq36YzbQ9hd9zH3j y6qKPySltwUa1E0a9jC/OSMTgDsi0NFj3P1lBS9IKXFb7tWFoLNLo83jmRcI17zWb+ezjqogWNZYI 20NhaWkRxwHdkfzdKPmdEtBYwUc44ptm2ZPT238ie/bIgscHr/gf9nxsVy1fkyn48Y+N7SLtXdjR3 NR9pEm1U1/BAujZ2LDj9FQ==; Date: Sun, 29 Jun 2025 09:05:55 +0300 Message-Id: <864ivz5bgc.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> (message from Phil Sainty on Sun, 29 Jun 2025 15:45:14 +1200) Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 29 Jun 2025 15:45:14 +1200 > From: Phil Sainty > Cc: monnier@iro.umontreal.ca, mail@daniel-mendler.de, 78719@debbugs.gnu.org, > drew.adams@oracle.com, juri@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. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 29 03:49:14 2025 Received: (at 78719) by debbugs.gnu.org; 29 Jun 2025 07:49:14 +0000 Received: from localhost ([127.0.0.1]:54665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVmmn-0002IC-Oo for submit@debbugs.gnu.org; Sun, 29 Jun 2025 03:49:14 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:36645 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVmmk-0002Gv-40 for 78719@debbugs.gnu.org; Sun, 29 Jun 2025 03:49:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7pBEfmzbW9AUd8s53xh3I2CdZPPKCAxGVDLsfiSYGhA=; b=wTG/B1yNwGZF3eFhMPX/E5oRL/ KzcsOAJ145jcD6yjKY5l8dqTtPB31xOF1YeVoA8ye+ybzDBoGcSTa7MDf/gF1Jszraew653iXlLwE DquCcXxjKngt4Er/4zAKBg3Vk6/BGz8xNaAjlKZlVWSx8kX6m9mOaCDaqoK9jHG7KZf0=; From: Daniel Mendler To: Eli Zaretskii Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <864ivz5bgc.fsf@gnu.org> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> Date: Sun, 29 Jun 2025 09:48:59 +0200 Message-ID: <877c0vhtsk.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Phil Sainty , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 08:05:31 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 12:05:32 +0000 Received: from localhost ([127.0.0.1]:42538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY1e1-0003kg-6R for submit@debbugs.gnu.org; Sat, 05 Jul 2025 08:05:30 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]:42495) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY1dq-0003fj-It for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 08:05:22 -0400 Received: from [10.253.37.70] (port=34606 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uY1dd-0006d9-EF; Sun, 06 Jul 2025 00:05:01 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sun, 06 Jul 2025 00:05:01 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Jul 2025 00:05:01 +1200 From: Phil Sainty To: Eli Zaretskii Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <864ivz5bgc.fsf@gnu.org> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> Message-ID: <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.5 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 08:35:20 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 12:35:20 +0000 Received: from localhost ([127.0.0.1]:42780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY26y-0008Hs-05 for submit@debbugs.gnu.org; Sat, 05 Jul 2025 08:35:20 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:51175 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY26t-0008EG-VT for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 08:35:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TflT1cQoEvHSOa8j2zqvYvMZZXqtjZwKcogn91tzPa0=; b=ciKDZEH8/amUdb9P/em38B4eqe pOIA1StOOl4odmRA+3xc73XaLHMNKSPKL0IyABcy026RfK94kTBZ7yoV8HjgeP7+2uVru7RJ6qIQY YjbEZHjB/XKDuFj7KZjb4ZShTj5P155ghdWYEqQtPwi7lHb9jvbE8gM0DARsC/t8pBhk=; From: Daniel Mendler To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> Date: Sat, 05 Jul 2025 14:35:06 +0200 Message-ID: <87ms9ieryd.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 09:05:02 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 13:05:02 +0000 Received: from localhost ([127.0.0.1]:43186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY2Zi-000488-1Q for submit@debbugs.gnu.org; Sat, 05 Jul 2025 09:05:02 -0400 Received: from smtp-3.orcon.net.nz ([60.234.4.44]:52291) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY2Zf-000476-9Y for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 09:05:00 -0400 Received: from [10.253.37.70] (port=62005 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uY2ZT-0005ew-QO; Sun, 06 Jul 2025 01:04:48 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sun, 06 Jul 2025 01:04:47 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Jul 2025 01:04:47 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87ms9ieryd.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> Message-ID: <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.5 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 09:15:32 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 13:15:32 +0000 Received: from localhost ([127.0.0.1]:43331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY2jr-0005nk-FI for submit@debbugs.gnu.org; Sat, 05 Jul 2025 09:15:32 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:39415 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY2jn-0005m5-0Q for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 09:15:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mtu4eoi6b1yY01y34VQ5I7xsEHzyTwzNV93eqAFZfIs=; b=Th8jT7FQPtnJkrCBms+yGWkEJL XjKEEk6ChpTXlf2xkgPwjtjA1U3stU4Z2GrRFIDMb+cc4C30VSs3YtN9cpDgrCVwD3CZOHL0XMtOw eB5d8MApv/kEIYJZD/bfUzci9rhgbfIy3et/2g8rwiIf6z1knVIK06omda4RPrVSSg1Q=; From: Daniel Mendler To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> Date: Sat, 05 Jul 2025 15:15:17 +0200 Message-ID: <87frfan5i2.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty 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=E2=80=99s 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-c= ase of the return value, except that it comes either from the user=E2=80=99= 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 09:37:11 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 13:37:11 +0000 Received: from localhost ([127.0.0.1]:43585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY34o-0000lf-D7 for submit@debbugs.gnu.org; Sat, 05 Jul 2025 09:37:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42738) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY34j-0000jt-R1 for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 09:37:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uY34a-0007rc-HS; Sat, 05 Jul 2025 09:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9ugW/sui8FAioVyTALIlZ5Nivnb6yyNR367sYAA50Cg=; b=BgAlh/Uyi/Ec fuYuoh18mtA/0TM92oTpg6BtR6sNrsvFFJ3YbOSZrVlTE7mcztuEP6aqy06Y1tmonhCGttPcW03Vt 5IuNEHNAA+ZdyTgXzzhNs3s/NDU0W0EZRYsg2u3/6Vn80FO7IPad6tqBhLNvLe8Tk8hMMdLlwM5Qj 8or5IWXhlkK3/EKEBhuzK0pzL+9Y6I+OfUHSf2wra+S0duC7CUWOiJUy2YYBYnLuat/iWyp7P/p27 GzWa973AZuu6Vy0uCZGZChgmLzPfH2pocsVD8Mt4iuciaS7qh4gl/O/DFToAS5jNpOzzI1kH6Cb1x U0Y92+SxCoSH0IL4WnFJkA==; Date: Sat, 05 Jul 2025 16:36:50 +0300 Message-Id: <86y0t2vjwt.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> (message from Phil Sainty on Sun, 06 Jul 2025 00:05:01 +1200) Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 06 Jul 2025 00:05:01 +1200 > From: Phil Sainty > Cc: monnier@iro.umontreal.ca, mail@daniel-mendler.de, 78719@debbugs.gnu.org, > drew.adams@oracle.com, juri@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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 10:04:42 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 14:04:43 +0000 Received: from localhost ([127.0.0.1]:45278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY3VQ-00059D-GN for submit@debbugs.gnu.org; Sat, 05 Jul 2025 10:04:42 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]:47401) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY3VN-00058Y-7P for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 10:04:38 -0400 Received: from [10.253.37.70] (port=33652 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uY3VD-0001DF-Ec; Sun, 06 Jul 2025 02:04:27 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sun, 06 Jul 2025 02:04:27 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Jul 2025 02:04:27 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87frfan5i2.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> Message-ID: <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.5 (-) On 2025-07-06 01:15, Daniel Mendler wrote: > Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 10:26:31 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 14:26:31 +0000 Received: from localhost ([127.0.0.1]:45521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY3qZ-00005p-45 for submit@debbugs.gnu.org; Sat, 05 Jul 2025 10:26:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35410) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY3qV-0008W7-Da for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 10:26:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uY3qM-0001vE-UP; Sat, 05 Jul 2025 10:26:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5Bp7VQTx9GgJ8zzu76/JV3JtgC+HH0+zr2WeokfCLOA=; b=XIPDBfPH5VyV VeuPDTTQ2Z5YQaL3//QhHB0RRaBXr8xRoQ2TBEzVcxMfCPU8ILekTIBqlbvAOTt2z4gOxvdMAylQB bnLazoG3XTg+Hm813hANNgNBjNdoH4/UcvSqE6mcNqo3qmmAeGlmmpcqYHpwuotQMGMkhFhvYANRX VO4fwQhF8Z8QOESqVJVi00MBui6u5kC9AUFplw25x+1WfOAUc3j3ttbtt0eB1xW2MKoMVy01qzV8M TVvAld9Xy4OVYD8MuROExubmzsHrn0Q7wpnRCnKXu0k8zd8pbEFr0Tcr1I72ZGLoH6TAwsrzNuAKa uwGbfJoE9rGlbTfJhEwMYg==; Date: Sat, 05 Jul 2025 17:26:16 +0300 Message-Id: <86wm8mvhmf.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> (message from Phil Sainty on Sun, 06 Jul 2025 02:04:27 +1200) Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 06 Jul 2025 02:04:27 +1200 > From: Phil Sainty > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 10:39:13 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 14:39:13 +0000 Received: from localhost ([127.0.0.1]:45707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY42p-0001sn-W0 for submit@debbugs.gnu.org; Sat, 05 Jul 2025 10:39:13 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:45733 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY42l-0001r9-Vc for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 10:39:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2/hE3Y7s6OXOwscvPbNzt9rugmqJFxqRijvTvySctDc=; b=rsMs+GwuAKNDNQfMjXKmf1PEnF h+hr7d0iE2KCjHWqnrqCpZsIkpH/Nfa5ni405Bh+CbpPJ22f9wQKd6UKcceiF00IgL94jP5qML4UJ mGE59hUw1IVmYUez/OCRLg1onxjMGKNoLrIE24Ue9yVWCI/jifYtpT3q3T0DKC7rtoic=; From: Daniel Mendler To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> Date: Sat, 05 Jul 2025 16:38:58 +0200 Message-ID: <87cyaen1ml.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty writes: > On 2025-07-06 01:15, Daniel Mendler wrote: >> Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 10:46:51 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 14:46:52 +0000 Received: from localhost ([127.0.0.1]:45823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY4AE-00036S-Cv for submit@debbugs.gnu.org; Sat, 05 Jul 2025 10:46:51 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:56595) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY4AC-00035r-NC for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 10:46:49 -0400 Received: from [10.253.37.70] (port=57910 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uY4A2-00015d-QO; Sun, 06 Jul 2025 02:46:39 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sun, 06 Jul 2025 02:46:38 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Jul 2025 02:46:38 +1200 From: Phil Sainty To: Eli Zaretskii Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <86y0t2vjwt.fsf@gnu.org> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <86y0t2vjwt.fsf@gnu.org> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.5 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 10:59:36 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 14:59:36 +0000 Received: from localhost ([127.0.0.1]:46004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY4Ma-0004yc-FK for submit@debbugs.gnu.org; Sat, 05 Jul 2025 10:59:36 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]:54491) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY4MY-0004y2-JY for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 10:59:35 -0400 Received: from [10.253.37.70] (port=32155 helo=webmail.orcon.net.nz) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uY4MO-0002PT-CQ; Sun, 06 Jul 2025 02:59:24 +1200 Received: from ip-115-69-187-4.as55850.net ([115.69.187.4]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Sun, 06 Jul 2025 02:59:24 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 06 Jul 2025 02:59:24 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87cyaen1ml.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.5 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 11:05:19 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 15:05:19 +0000 Received: from localhost ([127.0.0.1]:46090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY4S6-0005vD-4f for submit@debbugs.gnu.org; Sat, 05 Jul 2025 11:05:19 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:41291 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY4S1-0005q6-Ga for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 11:05:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lKmwbcKTWbK3nuVHSgyoJ+y1uYvC2HMlVGJa15bkEOU=; b=ivfg9rrYYQPHQQ+LcansxQtvgD nxXADxtofYeGpoA5r5UjYhSsWsgYVJ15dzoYASGybTCjlalGm3q1Y9XKRGLn+N5EiZmIghlX80OIv WtYv3JcTI+PI4o/cXT3d2dAE62eHRGCnZCp2UTJ7ddtm9U5IPcscrPFBwIA4iWoj6l5w=; From: Daniel Mendler To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <86y0t2vjwt.fsf@gnu.org> Date: Sat, 05 Jul 2025 17:05:04 +0200 Message-ID: <87a55in0f3.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 11:26:25 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 15:26:25 +0000 Received: from localhost ([127.0.0.1]:46250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY4mX-0000WS-0W for submit@debbugs.gnu.org; Sat, 05 Jul 2025 11:26:25 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27273) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY4mV-0000Vu-8d for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 11:26:23 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A885444154B; Sat, 5 Jul 2025 11:26:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1751729176; bh=PNDQxK+FYJhqC+yzO/iqPx+Q3A7wQrS7FhNljZxa75Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EvZBTICfG+jw/56UHLoCF/GsDJmmJgQ7NaMTHzt4C5DZ9OBIMmbfmQYuxiSPcD6X+ bzzNP0+ZsPYaB4g2hhoFSLFMYh7GrKC/0HAcPUhqQPtNUlt6vk99I6e3oXkTtpFSzD TcPnkJXq/FvbrykzHIPbbouI6Ko0cyH984kWeBPgO6WqBOcJtRe0m9uPcrN/cIKc1e 6nFnEi+/jJL22+q4vTyZ+QgWrvxaYUvp3XXUjpysnfUFlk3qLMCcvP5lWYyi3OLR8B R2pcBzgk2DCn7vRFDmaNn8U3JwM5Z6tafnsfaJ5AV6NtmQ0HI1HCqAkU8K/bkoMSCr 8s5ftDu45wM4g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BBCE6440F94; Sat, 5 Jul 2025 11:26:16 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7380C1204A3; Sat, 5 Jul 2025 11:26:16 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <86wm8mvhmf.fsf@gnu.org> Message-ID: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <86wm8mvhmf.fsf@gnu.org> Date: Sat, 05 Jul 2025 11:26:15 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.279 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 78719 Cc: Phil Sainty , mail@daniel-mendler.de, 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.1 (---) >> (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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 11:28:54 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 15:28:54 +0000 Received: from localhost ([127.0.0.1]:46260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY4ov-0000mJ-Rc for submit@debbugs.gnu.org; Sat, 05 Jul 2025 11:28:54 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:45275 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY4os-0000l0-Ne for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 11:28:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2MJ6e4qlD74L3hbXD27fNnXvHjmL48ynb7cjxbfl5is=; b=ZJF8x7nV08SlKbcKm5h/pUW96c BYo9SPuTHn+ksCQGuQb5FRVqu11BRJ6HcO+qVa9YX0q0jQ1hgUVlDcGjgDcfmk96TNKhVzcqC/S8E xJ9k/4ggnLTAqpeRZDtC5D7Bz7LSXQ5RaiS0OzbY07xgkwA6NSyh81E7EeTIN5Gw1SJk=; From: Daniel Mendler To: Stefan Monnier Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <86wm8mvhmf.fsf@gnu.org> Date: Sat, 05 Jul 2025 17:28:40 +0200 Message-ID: <874ivqmzbr.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Phil Sainty , Eli Zaretskii , 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Stefan Monnier 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 05 11:29:23 2025 Received: (at 78719) by debbugs.gnu.org; 5 Jul 2025 15:29:23 +0000 Received: from localhost ([127.0.0.1]:46265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uY4pP-0000qK-Eo for submit@debbugs.gnu.org; Sat, 05 Jul 2025 11:29:23 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:37551 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uY4pN-0000pK-6y for 78719@debbugs.gnu.org; Sat, 05 Jul 2025 11:29:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=91p/hFNQeyvtAE3haullNtabzVe4Hcb8/rgnIdk1t9Q=; b=Ty5RoUrOXHdlVH3L3PbEIJUWnS urvxDt8QFzyoPBvAkexNrEl7h0c43rSdQtp5Oc57tdQKqmz5KYEEJaNu5Go/wbvdCV1X0HypsAyBF KXy1xL96OhsGwqd2M/ztcSmtH3A3AJNvgpz7otS2Ue4PVQjZSQpl8K5n9CRUxKlO2iOY=; From: Daniel Mendler To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> Date: Sat, 05 Jul 2025 17:29:12 +0200 Message-ID: <87zfdilkqf.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Phil Sainty 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 18 00:01:26 2025 Received: (at 78719) by debbugs.gnu.org; 18 Jul 2025 04:01:26 +0000 Received: from localhost ([127.0.0.1]:59250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uccHl-0001rN-UH for submit@debbugs.gnu.org; Fri, 18 Jul 2025 00:01:26 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:40757) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uccHj-0001r2-9e for 78719@debbugs.gnu.org; Fri, 18 Jul 2025 00:01:24 -0400 Received: from [10.253.37.70] (port=46060 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1uccHU-0000GP-G1; Fri, 18 Jul 2025 16:01:08 +1200 Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 18 Jul 2025 16:01:08 +1200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_00d7a6109b94e18c0e39b00c2fb6f0c4" Date: Fri, 18 Jul 2025 16:01:08 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87zfdilkqf.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> <87zfdilkqf.fsf@daniel-mendler.de> Message-ID: X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=_00d7a6109b94e18c0e39b00c2fb6f0c4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2025-07-06 03:29, Daniel Mendler wrote: > 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) I'm happy to proceed with either option. I figured that a potential argument for keeping the filter arguments is efficiency, so I've done some benchmarking. (I've included the PREDICATE filter in my benchmarks for completeness, but unless others change their minds I'm not looking to include that -- and my results don't support it for performance reasons in any case.) For a collection of strings, I used the symbol names from the obarray after running "emacs -Q" (for my build of 30.1-ish), which gave me 18271 strings (this is my "small data set"). I repeated the benchmarks in my regular instance of Emacs (not -Q), which has been running for a while, and that has 91167 strings (my "large data set"). I used string-common-prefix to obtain the common prefix "buffer" after filtering the collection to only the strings beginning with "buf", using each of the three filter options. I've attached a file with the specific process I used. Besides using the filter args, I compared two ways of filtering the COLLECTION in advance. The "cl-loop ... collect" approach only generates the desired list, whereas the "mapcar" approach is also generating a ton of nil values which need deleting, so that approach produces a lot of garbage (it caused 100 gcs on the large data set, which dominates the time taken). (I figure this would still be something that some folks would do in practice though.) I've only shown `benchmark-run-compiled' results. With uncompiled `benchmark-run', the mapcar and cl-loop approachs get significantly slower, but that probably isn't a consideration. I ran each benchmark repeatedly and have shown a representative result of the most-common timing. My results were: 1. STRING filter A: small data set: - filter arg took 0.06 seconds - cl-loop took 0.11 seconds (1.8 times as long) - mapcar took 0.72 seconds (12 times as long) B: large data set: - filter arg took 0.22 seconds - cl-loop took 0.44 seconds (2 times as long) - mapcar took 2.24 seconds (10.4 times as long) 2. REGEXP-LIST filter A: small data set: - filter arg took 0.16 seconds - cl-loop took 0.14 seconds (0.9 times as long) - mapcar took 0.75 seconds (4.6 times as long) B: large data set: - filter arg took 0.72 seconds - cl-loop took 0.65 seconds (0.9 times as long) - mapcar took 2.40 seconds (3.3 times as long) 3. PREDICATE filter A: small data set: - filter arg took 0.17 seconds - cl-loop took 0.11 seconds (0.6 times as long) - mapcar took 0.79 seconds (4.8 times as long) B: large data set: - filter arg took 0.76 seconds - cl-loop took 0.46 seconds (0.6 times as long) - mapcar took 2.49 seconds (3.3 times as long) So the STRING filter was significantly faster when performed by `try-completion' directly, but I got a faster result for the REGEXP-LIST and PREDICATE filters when pre-filtering the collection using the cl-loop ... collect approach. I guess that there's some additional overhead for `try-completion' in those cases. Anyone who was inclined to filter their collections using a mapcar/delq combination may certainly benefit from having the filter arguments available. That aside, the benefit of a REGEXP-LIST filter would seem to be purely one of convenience rather than performance (unless the comparative slowness when try-completion handles the regexp list turned out to be some inefficiency which can be addressed). -Phil --=_00d7a6109b94e18c0e39b00c2fb6f0c4 Content-Transfer-Encoding: base64 Content-Type: text/x-lisp; name=bug-78719-benchmark-tests.el Content-Disposition: attachment; filename=bug-78719-benchmark-tests.el; size=2769 KGRlZnZhciBteXN0cmluZ3MgKGxldCAoc3RyaW5ncykKICAgICAgICAgICAgICAgICAgICAobWFw YXRvbXMgKGxhbWJkYSAoc3ltKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChwdXNo IChzeW1ib2wtbmFtZSBzeW0pIHN0cmluZ3MpKSkKICAgICAgICAgICAgICAgICAgICBzdHJpbmdz KSkKCihsZW5ndGggbXlzdHJpbmdzKQo7OyAxODI3MQoKCjs7IEkndmUgdGVzdGVkIHRocmVlIGRp ZmZlcmVudCB3YXlzIG9mIG9idGFpbmluZyB0aGUgY29tbW9uIHByZWZpeAo7OyAiYnVmZmVyIiBm cm9tIG15IGxpc3Qgb2Ygc3ltYm9sIG5hbWVzLCB3aGVuIGZpbHRlcmVkIHRvIHRoZQo7OyBzdHJp bmdzIGJlZ2lubmluZyB3aXRoICJidWYiLgoKKHN0cmluZy1jb21tb24tcHJlZml4IG15c3RyaW5n cyAiYnVmIikgOzsgU1RSSU5HCihzdHJpbmctY29tbW9uLXByZWZpeCBteXN0cmluZ3MgbmlsIG5p bCAnKCJcXGBidWYiKSkgOzsgUkVHRVhQLUxJU1QKKHN0cmluZy1jb21tb24tcHJlZml4IG15c3Ry aW5ncyBuaWwgbmlsIG5pbCA7OyBQUkVESUNBVEUKICAgICAgICAgICAgICAgICAgICAgIChsYW1i ZGEgKHN0cikKICAgICAgICAgICAgICAgICAgICAgICAgKHN0cmluZy1wcmVmaXgtcCAiYnVmIiBz dHIpKSkKCgo7OyAxLiBNaW5pbXVtIHByZWZpeCBzdHJpbmcgZmlsdGVyCgo7OyAxYS4gc3RyaW5n LWNvbW1vbi1wcmVmaXggYXJndW1lbnQKKGJlbmNobWFyay1ydW4tY29tcGlsZWQgMTAwCiAgKHN0 cmluZy1jb21tb24tcHJlZml4IG15c3RyaW5ncyAiYnVmIikpCjs7ICgwLjA1OTU2NjAyMSAwIDAu MCkKCjs7IDFiLiBjbC1sb29wIC4uLiBjb2xsZWN0CihiZW5jaG1hcmstcnVuLWNvbXBpbGVkIDEw MAogIChzdHJpbmctY29tbW9uLXByZWZpeAogICAoY2wtbG9vcCBmb3Igc3RyIGluIG15c3RyaW5n cwogICAgICAgICAgICBpZiAoc3RyaW5nLXByZWZpeC1wICJidWYiIHN0cikKICAgICAgICAgICAg Y29sbGVjdCBzdHIpKSkKOzsgKDAuMTA4MzM2NzAxIDAgMC4wKQoKOzsgMWMuIG1hcGNhcgooYmVu Y2htYXJrLXJ1bi1jb21waWxlZCAxMDAKICAoc3RyaW5nLWNvbW1vbi1wcmVmaXgKICAgKGRlbHEg bmlsIChtYXBjYXIgKGxhbWJkYSAoc3RyKQogICAgICAgICAgICAgICAgICAgICAgIChhbmQgKHN0 cmluZy1wcmVmaXgtcCAiYnVmIiBzdHIpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHIp KQogICAgICAgICAgICAgICAgICAgICBteXN0cmluZ3MpKSkpCjs7ICgwLjcxNTYyMDI1NiAzMyAw LjQ5MTg5MTY1ODAwMDAwMDEpCgoKOzsgMi4gUmVnZXhwIGZpbHRlcgoKOzsgMmEuIHN0cmluZy1j b21tb24tcHJlZml4IGFyZ3VtZW50CihiZW5jaG1hcmstcnVuLWNvbXBpbGVkIDEwMAogIChzdHJp bmctY29tbW9uLXByZWZpeCBteXN0cmluZ3MgbmlsIG5pbCAnKCJcXGBidWYiKSkpCjs7ICgwLjE2 MzE2MDcwNSAwIDAuMCkKCjs7IDJiLiBjbC1sb29wIC4uLiBjb2xsZWN0CihiZW5jaG1hcmstcnVu LWNvbXBpbGVkIDEwMAogIChzdHJpbmctY29tbW9uLXByZWZpeAogICAoY2wtbG9vcCBmb3Igc3Ry IGluIG15c3RyaW5ncwogICAgICAgICAgICBpZiAoc3RyaW5nLW1hdGNoICJcXGBidWYiIHN0cikK ICAgICAgICAgICAgY29sbGVjdCBzdHIpKSkKOzsgKDAuMTQxMDg0MzcwMDAwMDAwMDEgMCAwLjAp Cgo7OyAyYy4gbWFwY2FyCihiZW5jaG1hcmstcnVuLWNvbXBpbGVkIDEwMAogIChzdHJpbmctY29t bW9uLXByZWZpeAogICAoZGVscSBuaWwgKG1hcGNhciAobGFtYmRhIChzdHIpCiAgICAgICAgICAg ICAgICAgICAgICAgKGFuZCAoc3RyaW5nLW1hdGNoICJcXGBidWYiIHN0cikKICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHN0cikpCiAgICAgICAgICAgICAgICAgICAgIG15c3RyaW5ncykpKSkK OzsgKDAuNzUwNjg2MTk1IDMzIDAuNDg2NzI0NzQyOTk5OTk5OSkKCgo7OyAzLiBQcmVkaWNhdGUg ZmlsdGVyCgo7OyAzYS4gc3RyaW5nLWNvbW1vbi1wcmVmaXggYXJndW1lbnQKKGJlbmNobWFyay1y dW4tY29tcGlsZWQgMTAwCiAgKHN0cmluZy1jb21tb24tcHJlZml4IG15c3RyaW5ncyBuaWwgbmls IG5pbAogICAgICAgICAgICAgICAgICAgICAgICAobGFtYmRhIChzdHIpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgKHN0cmluZy1wcmVmaXgtcCAiYnVmIiBzdHIpKSkpCjs7ICgwLjE2NTI1Nzc0 MiAwIDAuMCkKCjs7IDNiLiBjbC1sb29wIC4uLiBjb2xsZWN0CihiZW5jaG1hcmstcnVuLWNvbXBp bGVkIDEwMAogIChjbC1mbGV0ICgocHJlZCAobGFtYmRhIChzdHIpCiAgICAgICAgICAgICAgICAg ICAgKHN0cmluZy1wcmVmaXgtcCAiYnVmIiBzdHIpKSkpCiAgICAoc3RyaW5nLWNvbW1vbi1wcmVm aXgKICAgICAoY2wtbG9vcCBmb3Igc3RyIGluIG15c3RyaW5ncwogICAgICAgICAgICAgIGlmIChw cmVkIHN0cikKICAgICAgICAgICAgICBjb2xsZWN0IHN0cikpKSkKOzsgKDAuMTA2MTIxMDYxIDAg MC4wKQoKOzsgM2MuIG1hcGNhcgooYmVuY2htYXJrLXJ1bi1jb21waWxlZCAxMDAKICAoY2wtZmxl dCAoKHByZWQgKGxhbWJkYSAoc3RyKQogICAgICAgICAgICAgICAgICAgIChzdHJpbmctcHJlZml4 LXAgImJ1ZiIgc3RyKSkpKQogICAgKHN0cmluZy1jb21tb24tcHJlZml4CiAgICAgKGRlbHEgbmls IChtYXBjYXIgKGxhbWJkYSAoc3RyKQogICAgICAgICAgICAgICAgICAgICAgICAgKGFuZCAocHJl ZCBzdHIpIHN0cikpCiAgICAgICAgICAgICAgICAgICAgICAgbXlzdHJpbmdzKSkpKSkKOzsgKDAu Nzg2NjkyMTczOTk5OTk5OSAzMyAwLjQ4OTE2NDU1MSkK --=_00d7a6109b94e18c0e39b00c2fb6f0c4-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 18 02:29:33 2025 Received: (at 78719) by debbugs.gnu.org; 18 Jul 2025 06:29:33 +0000 Received: from localhost ([127.0.0.1]:59868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uceb7-0006GG-8w for submit@debbugs.gnu.org; Fri, 18 Jul 2025 02:29:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51600) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uceb4-0006Fu-CA for 78719@debbugs.gnu.org; Fri, 18 Jul 2025 02:29:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uceau-00054f-Nk; Fri, 18 Jul 2025 02:29:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xCGsgtdNLw5cLUpY75GqgMiF4sle1KsumsrfHl9zbCg=; b=Bl385r8jaMRE VB12WnnSuaci3CcxLRFxxO9Lo4KYw1y8duA1AmwedUnUSvcsAoW76Q+WwE3kFPQXwBbLjq5NY7+Ja HvEMmkWIqjwJehFTlt908MMZmuMjt5LPWX0RzVIkDl72LitP8uogQUOIWkbO1ZMlW9pex5Y8DPsC5 tRgjQHUAB3f0m8hq4OXN2jDihjrDFK3Or28h+m1tV+8nhQyX4hOkrYjK3FQkSEt97/5BkJNbgMS8M pEsVXm52X2K8R01kQaPaAk5G/GkdqCKwkTi3qUh5Xq+cTOALOGt8ttXTez7AbL7EZWKfawEt0Gplk 3kaWLXuCpV+l9VCwdVoPBQ==; Date: Fri, 18 Jul 2025 09:29:16 +0300 Message-Id: <86o6tif1vn.fsf@gnu.org> From: Eli Zaretskii To: Phil Sainty In-Reply-To: (message from Phil Sainty on Fri, 18 Jul 2025 16:01:08 +1200) Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> <87zfdilkqf.fsf@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: mail@daniel-mendler.de, juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 18 Jul 2025 16:01:08 +1200 > From: Phil Sainty > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net > > On 2025-07-06 03:29, Daniel Mendler wrote: > > 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) > > I'm happy to proceed with either option. My vote is for the much simpler latter API, even after reading your benchmarks. I thought having such a simple API was the goal from the get-go. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 18 05:38:32 2025 Received: (at 78719) by debbugs.gnu.org; 18 Jul 2025 09:38:32 +0000 Received: from localhost ([127.0.0.1]:60694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uchY0-0005Rb-64 for submit@debbugs.gnu.org; Fri, 18 Jul 2025 05:38:32 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:57497 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uchXw-0005R4-7g for 78719@debbugs.gnu.org; Fri, 18 Jul 2025 05:38:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4sHmUgpaWQ4dgNUdJHYwSgr1XohhPHtFPJYPyNvsISg=; b=UMfRk1pBeKm5IQZJHrrNa9Wc4W hWyPC5Jb4RKQdRn/hWLfJ6Zwtaplv4b727rFinw4p7RZnGa1hIVm7mUqKniC5i95qq2ns/Wl1JAlM /2Sh+jpI4qB7STVjIyFXn4UcZBCwtiXIqDRkrnSEHFOqJ17DGHbyrhIhlwgpmqvNoCfw=; From: Daniel Mendler To: Eli Zaretskii Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <86o6tif1vn.fsf@gnu.org> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> <87zfdilkqf.fsf@daniel-mendler.de> <86o6tif1vn.fsf@gnu.org> Date: Fri, 18 Jul 2025 11:38:18 +0200 Message-ID: <87ikjpbzzp.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Phil Sainty , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> Date: Fri, 18 Jul 2025 16:01:08 +1200 >> From: Phil Sainty >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, >> 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net >> >> On 2025-07-06 03:29, Daniel Mendler wrote: >> > 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) >> >> I'm happy to proceed with either option. > > My vote is for the much simpler latter API, even after reading your > benchmarks. I thought having such a simple API was the goal from the > get-go. I am okay with the simpler API. If users want filtering functionality, they can use `try-completion' (for a common prefix) or `all-completions' (for matching candidates) directly. The docstring of `string-common-prefix' should point users to `try-completion', where they can find the advanced filtering functionality beyond simple prefix computation. Daniel From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 18 07:33:52 2025 Received: (at 78719) by debbugs.gnu.org; 18 Jul 2025 11:33:52 +0000 Received: from localhost ([127.0.0.1]:32861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ucjLb-0007ed-AL for submit@debbugs.gnu.org; Fri, 18 Jul 2025 07:33:52 -0400 Received: from smtp-1.orcon.net.nz ([60.234.4.34]:33515) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ucjLQ-0007dm-Gx for 78719@debbugs.gnu.org; Fri, 18 Jul 2025 07:33:46 -0400 Received: from [10.253.37.70] (port=64916 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1ucjLC-0003Kv-Mi; Fri, 18 Jul 2025 23:33:27 +1200 Received: from ip-139-180-104-251.as55850.net ([139.180.104.251]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 18 Jul 2025 23:33:26 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 Jul 2025 23:33:26 +1200 From: Phil Sainty To: Daniel Mendler Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: <87ikjpbzzp.fsf@daniel-mendler.de> References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> <87zfdilkqf.fsf@daniel-mendler.de> <86o6tif1vn.fsf@gnu.org> <87ikjpbzzp.fsf@daniel-mendler.de> Message-ID: <87cee872f36e1d7e1785795599414c0c@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78719 Cc: Eli Zaretskii , juri@linkov.net, monnier@iro.umontreal.ca, drew.adams@oracle.com, 78719@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 2025-07-18 21:38, Daniel Mendler wrote: > Eli Zaretskii writes: >> My vote is for the much simpler latter API > > I am okay with the simpler API. If users want filtering functionality, > they can use `try-completion' (for a common prefix) or > `all-completions' > (for matching candidates) directly. The docstring of > `string-common-prefix' should point users to `try-completion', where > they can find the advanced filtering functionality beyond simple prefix > computation. Thanks both; decision made, then. I'll update the patch for review sometime soon. -Phil From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 23 12:50:11 2025 Received: (at 78719) by debbugs.gnu.org; 23 Jul 2025 16:50:12 +0000 Received: from localhost ([127.0.0.1]:51414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uecfS-0004gI-Vj for submit@debbugs.gnu.org; Wed, 23 Jul 2025 12:50:11 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50866) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uecfO-0004aU-Jx for 78719@debbugs.gnu.org; Wed, 23 Jul 2025 12:50:08 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D8945809A6; Wed, 23 Jul 2025 12:50:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1753289400; bh=CTlPqEc7avYqf419GNKCvDkQDPI5BHtohambpOdbUpA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ILYqtdi0uz4xrI1kSP2d0gPxPPt7MpkhapHJkK/9RzUwiQcIJ8qIWwDKEaG2P7+Qq W5vrPOns3R3JJcvxoqkIMJynBUy3havURpCXKaPYtMK/ZmxXBYB8b39+K8DhJvcj4k 2wzQnqyiSZNMrmWIqrzl41+TMNRQv1C6psyO/0sQmFR/C7J8Zc9/9r6Xl4/sr9TrN2 mbou7IxuRkyy1MnfvBt7sGiN5haM758b5AY9DCjMdvyh9tvQtCYy0F1EzuzT4RmU/J gjh2jO7nIWuh5O1qJPAYQj0J0B6pEsk4JKbHUWyN80kMi+XZ70cpcKQ3wx8yZeI0ut JMgpZw0gOFlGA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F36C0803A3; Wed, 23 Jul 2025 12:49:59 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E5723120E9B; Wed, 23 Jul 2025 12:49:59 -0400 (EDT) From: Stefan Monnier To: Phil Sainty Subject: Re: bug#78719: 30.1; [PATCH] Add functions `string-common-prefix' and `string-try-completion' In-Reply-To: Message-ID: References: <670a52b1ddc8a9a97a6ce308e628235d@webmail.orcon.net.nz> <87wm9mh19b.fsf@daniel-mendler.de> <87ldq141zp.fsf@daniel-mendler.de> <293f3fe2d3d4a0a9d11e6db9d0f2a1ba@webmail.orcon.net.nz> <864iwnfw98.fsf@gnu.org> <84a744c21a3531388c64815895f9f61d@webmail.orcon.net.nz> <864ivz5bgc.fsf@gnu.org> <4c9a815d0b57e9c98ab1c8f5c687a71c@webmail.orcon.net.nz> <87ms9ieryd.fsf@daniel-mendler.de> <93c8c642fd87a179d714e6cd46164c54@webmail.orcon.net.nz> <87frfan5i2.fsf@daniel-mendler.de> <02d89b1e90bb97261965194e979d31b4@webmail.orcon.net.nz> <87cyaen1ml.fsf@daniel-mendler.de> <87zfdilkqf.fsf@daniel-mendler.de> Date: Wed, 23 Jul 2025 12:49:51 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.153 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78719 Cc: Daniel Mendler , Eli Zaretskii , 78719@debbugs.gnu.org, drew.adams@oracle.com, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 1. STRING filter > > A: small data set: > - filter arg took 0.06 seconds > - cl-loop took 0.11 seconds (1.8 times as long) > > B: large data set: > - filter arg took 0.22 seconds > - cl-loop took 0.44 seconds (2 times as long) Fair enough. > 2. REGEXP-LIST filter > > A: small data set: > - filter arg took 0.16 seconds > - cl-loop took 0.14 seconds (0.9 times as long) > > B: large data set: > - filter arg took 0.72 seconds > - cl-loop took 0.65 seconds (0.9 times as long) Interesting. I can't think of any reason why the C-level calls to match the regexp would be slower than going through ELisp. What makes it even more surprising is that the ELisp code does more work: - it allocates an intermediate list. - it does case-insensitive matching (assuming `completion-ignore-case` was nil but `case-fold-search` was not). > 3. PREDICATE filter > > A: small data set: > - filter arg took 0.17 seconds > - cl-loop took 0.11 seconds (0.6 times as long) > > B: large data set: > - filter arg took 0.76 seconds > - cl-loop took 0.46 seconds (0.6 times as long) Interesting as well. Here I suspect that the byte-compiler inlined the `pred` into its call turning (benchmark-run-compiled 100 (cl-flet ((pred (lambda (str) (string-prefix-p "buf" str)))) (string-common-prefix (cl-loop for str in mystrings if (pred str) collect str)))) into (benchmark-run-compiled 100 (string-common-prefix (cl-loop for str in mystrings if (string-prefix-p "buf" str) collect str))) Otherwise, I'd say that we're seeing the effect of the "fastpath" when a bytecode function calls another bytecode function, where we avoid the cost of leaving+entering the bytecode interpreter. In any case, your test suggests the only advantage of the current filtering system of `try-completion` is that the prefix filtering is faster in C and that we will usually want to first filter with a prefix and only after that do regexp or pred filtering on the remaining candidates. This said, in practice, `minibuffer.el` rarely uses those fancy filtering system on `try-completion`: instead it uses them on `all-completions` and then uses `try-completion` on (various parts of) the resulting list of candidates without any filtering, Stefan