From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] * lisp/subr.el (string-suffix-p): New function. Date: Fri, 22 Nov 2013 12:00:29 +0200 Message-ID: References: <96EB3F8805134461A3BA58983F643449@gmail.com> <8738mo4x69.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b5d2ea4863bf004ebc11550 X-Trace: ger.gmane.org 1385114434 30457 80.91.229.3 (22 Nov 2013 10:00:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Nov 2013 10:00:34 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 22 11:00:40 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VjnXU-0006SN-EF for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 11:00:40 +0100 Original-Received: from localhost ([::1]:37767 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjnXU-0003Dz-5i for ged-emacs-devel@m.gmane.org; Fri, 22 Nov 2013 05:00:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjnXP-0003Ds-DM for emacs-devel@gnu.org; Fri, 22 Nov 2013 05:00:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjnXK-0006xv-Es for emacs-devel@gnu.org; Fri, 22 Nov 2013 05:00:35 -0500 Original-Received: from mail-oa0-x229.google.com ([2607:f8b0:4003:c02::229]:49045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjnXK-0006xr-71 for emacs-devel@gnu.org; Fri, 22 Nov 2013 05:00:30 -0500 Original-Received: by mail-oa0-f41.google.com with SMTP id j17so1115549oag.28 for ; Fri, 22 Nov 2013 02:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=V4YJmOnGHOzN9mwcbPPHifnky3dtbo4VY/Y30Bmeesg=; b=emmgBdeqo1vo9LHKHATDiY5acpbYv/eqDbo2RJbsgkvrg/F7m4Xzkxqg40Hl4eNE8q +MU4Fsg/R/t8XXxS7qO1AGnKk7AsK74cmfFMUarTDB+wv1ABFsA8bdq196XqD/8l4rT/ ZKhNk7T33IJrOvemj2UOrxDQsJw9TjoDkEe+O/LUAS3OWDk//ysfg+3HHSUNc8Kzycil 0JUbFQyXnPp+PajcTTI3fA11h2HP3/ClpWyTg2aPTVWt0U3nyoewTTTdvIPI2ZJxZR9B SNWP0noyqxtQzsMkzdPrQTYxu5kisaHB6PIDOI0haD+/OVfVB0nbHoon1rpP6XfDZbLT daCA== X-Received: by 10.182.49.166 with SMTP id v6mr9832192obn.13.1385114429173; Fri, 22 Nov 2013 02:00:29 -0800 (PST) Original-Received: by 10.76.21.207 with HTTP; Fri, 22 Nov 2013 02:00:29 -0800 (PST) In-Reply-To: <8738mo4x69.fsf@zigzag.favinet> X-Google-Sender-Auth: zRgIkrqN8x3V8Q3o5oWOcOFD8Po X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165546 Archived-At: --047d7b5d2ea4863bf004ebc11550 Content-Type: text/plain; charset=UTF-8 I've mentioned only the symmetry, but obviously I think we need this (and a bunch of other string related functions, since currently the string related functions are a bit lacking), otherwise I would have not submitted this suggestion. I've often needed in my code this particular check and I'd suggest include a few string related functions as well. Just a quick glance at the number of projects using the third-party string library s.el (https://github.com/magnars/s.el/blob/master/s.el) should be all the motivation required to improve upon the existing string functions. I think it's quite important to provide an API closer to that of popular programming languages, used often for text processing(Perl, Python, Ruby, etc). That would include functions like: * string-join * string-trim/string-trim-left/string-trim-right * string-chop * string-chomp The best text editor in the world should have an extensive built-in string manipulation API, right? On 22 November 2013 11:12, Thien-Thi Nguyen wrote: > () Bozhidar Batsov > () Fri, 22 Nov 2013 09:06:10 +0200 > > No comments == no objections? :-) > > I think symmetry alone is insufficient motivation. Whether > or not that design guideline is appropriate here (for Emacs) > is another question. > > Generally, you can make a better case for inclusion if you > find many places in the code base where the function can be > used. Another way to improve its prospects is to show new > (and cool) code that would not be possible w/o the function. > > As i see it, no comments == no invitation. > > -- > Thien-Thi Nguyen > GPG key: 4C807502 > (if you're human and you know it) > read my lisp: (responsep (questions 'technical) > (not (via 'mailing-list))) > => nil > --047d7b5d2ea4863bf004ebc11550 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've mentioned only the symmetry, but obviously I thin= k we need this (and a bunch of other string related functions, since curren= tly the string related functions are a bit lacking), otherwise I would have= not submitted this suggestion. I've often needed in my code this parti= cular check and I'd suggest include a few string related functions as w= ell.

Just a quick glance at the number of projects using the= third-party string library s.el (https://github.com/magnars/s.el/blob/master/s.el) s= hould be all the motivation required to improve upon the existing string fu= nctions. I think it's quite important to provide an API closer to that = of popular programming languages, used often for text processing(Perl, Pyth= on, Ruby, etc). That would include functions like:

* string-join
* string-trim/string-trim-left/= string-trim-right
* string-chop
* string-chomp

The best text editor in the world should have an exten= sive built-in string manipulation API, right?


On 22 No= vember 2013 11:12, Thien-Thi Nguyen <ttn@gnu.org> wrote:
() Bozhidar Batsov <bozhidar@bats= ov.com>
() Fri, 22 Nov 2013 09:06:10 +0200

=C2=A0 =C2=A0No comments =3D=3D no objections? :-)

I think symmetry alone is insufficient motivation. =C2=A0Whether
or not that design guideline is appropriate here (for Emacs)
is another question.

Generally, you can make a better case for inclusion if you
find many places in the code base where the function can be
used. =C2=A0Another way to improve its prospects is to show new
(and cool) code that would not be possible w/o the function.

As i see it, no comments =3D=3D no invitation.

--
Thien-Thi Nguyen
=C2=A0 =C2=A0GPG key: 4C807502
=C2=A0 =C2=A0(if you're human and you know it)
=C2=A0 =C2=A0 =C2=A0 read my lisp: (responsep (questions 'technical) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not (via 'mailing-list)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=3D> nil

--047d7b5d2ea4863bf004ebc11550--