From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Trimming strings, /emacs/lisp/emacs-lisp/subr-x.el modification Date: Sat, 6 May 2017 09:30:46 -0700 (PDT) Message-ID: <0d4cb885-4bea-44d5-8a19-5b77773db563@default> References: <87vapij1l7.fsf@holos> <6870A2B6-F685-4955-9C0A-256601DB47BC@gmail.com> <51D5E92C-F125-4ADE-8C55-E3513C00ECDC@gmail.com> <8F6958D6-3E13-4C31-B1F8-AF10A8FC8FC6@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1494088291 2432 195.159.176.226 (6 May 2017 16:31:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 May 2017 16:31:31 +0000 (UTC) Cc: Mark Oteiza , emacs-devel To: Jean-Christophe Helary , Tino Calancha Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 06 18:31:26 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d72cA-0000Tb-0n for ged-emacs-devel@m.gmane.org; Sat, 06 May 2017 18:31:26 +0200 Original-Received: from localhost ([::1]:52114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d72cE-0000Xi-4v for ged-emacs-devel@m.gmane.org; Sat, 06 May 2017 12:31:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d72be-0000XR-LD for emacs-devel@gnu.org; Sat, 06 May 2017 12:30:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d72bb-0001dx-Be for emacs-devel@gnu.org; Sat, 06 May 2017 12:30:54 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:30359) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d72ba-0001dd-Si for emacs-devel@gnu.org; Sat, 06 May 2017 12:30:51 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v46GUlVd025926 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 May 2017 16:30:47 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v46GUldO001584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 May 2017 16:30:47 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v46GUkwm002917; Sat, 6 May 2017 16:30:46 GMT In-Reply-To: <8F6958D6-3E13-4C31-B1F8-AF10A8FC8FC6@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214625 Archived-At: > > +(defsubst string-trim-left (string &optional regexp) > > + "Trim STRING of leading whitespace matching REGEXP. > > + > > +REGEXP defaults to \"[ \t\n\r]+\"." > > + (if (string-match (concat "\\`" (or regexp "[ \t\n\r]+")) string) > > (replace-match "" t t string) > > string)) > > Isn't there a way to do [...] that would work with defsubst? IMHO, *none* of the defsubsts in subr-x.el should be there. They should all be defuns. (Currently, even their names are inconsistent, some with `--' to indicate internal, most not.) The code will be byte-compiled. I see zero reason why these functions should be defsubsts. Instead of using a boatload of defsubsts willy nilly, any defsubsts we put in the code should be _strongly_ justified. I don't see any justification for these defsubsts. It's not just because `defsubst' still exists that we should use it casually (or even use it at all). It is a precambrian vestige, with little or no real use case. Just one opinion.