[PATCH] * lisp/subr.el (string-suffix-p): New function.

[PATCH] * lisp/subr.el (string-suffix-p): New function.

[Bozhidar Batsov]

[-- Attachment #1.1: Type: text/plain, Size: 298 bytes --]

Hi guys,  

We do have `string-prefix-p' function, but oddly enough we didn’t have a matching `string-suffix-p', so I’ve implemented it.

I also think it might be a good idea to alias those two functions to `string-starts-with-p' and `string-ends-with-p’.  

--  
Cheers,
Bozhidar


[-- Attachment #1.2: Type: text/html, Size: 670 bytes --]

[-- Attachment #2: 0001-lisp-subr.el-string-suffix-p-New-function.patch --]
[-- Type: application/octet-stream, Size: 1451 bytes --]

From f73541c4bc69bc4bb703fb62c87be059bbbba516 Mon Sep 17 00:00:00 2001
From: Bozhidar Batsov <bozhidar@batsov.com>
Date: Wed, 20 Nov 2013 13:17:07 +0200
Subject: [PATCH] * lisp/subr.el (string-suffix-p): New function.

---
 lisp/ChangeLog | 4 ++++
 lisp/subr.el   | 9 +++++++++
 2 files changed, 13 insertions(+)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 357087d..0acdf62 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,7 @@
+2013-11-20  Bozhidar Batsov  <bozhidar@batsov.com>
+
+	* subr.el (string-suffix-p): New function.
+
 2013-11-20  era eriksson  <era+emacsbugs@iki.fi>
 
 	* ses.el (ses-mode): Doc fix.  (Bug#14748)
diff --git a/lisp/subr.el b/lisp/subr.el
index 31798b4..b22c719 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3635,6 +3635,15 @@ to case differences."
   (eq t (compare-strings str1 nil nil
                          str2 0 (length str1) ignore-case)))
 
+(defun string-suffix-p (suffix string  &optional ignore-case)
+  "Return non-nil if SUFFIX is a suffix of STRING.
+If IGNORE-CASE is non-nil, the comparison is done without paying
+attention to case differences."
+  (let ((start-pos (- (length string) (length suffix))))
+    (and (>= start-pos 0)
+         (eq t (compare-strings suffix nil nil
+                                string start-pos nil ignore-case)))))
+
 (defun bidi-string-mark-left-to-right (str)
   "Return a string that can be safely inserted in left-to-right text.
 
-- 
1.8.4

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

No comments == no objections? :-)


On 20 November 2013 13:24, Bozhidar Batsov <bozhidar@batsov.com> wrote:

>  Hi guys,
>
> We do have `string-prefix-p' function, but oddly enough we didn’t have a
> matching `string-suffix-p', so I’ve implemented it.
>
> I also think it might be a good idea to alias those two functions to
> `string-starts-with-p' and `string-ends-with-p’.
>
> --
> Cheers,
> Bozhidar
>
>

[-- Attachment #2: Type: text/html, Size: 1145 bytes --]

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

() Bozhidar Batsov <bozhidar@batsov.com>
() 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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

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 <ttn@gnu.org> wrote:

> () Bozhidar Batsov <bozhidar@batsov.com>
> () 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
>

[-- Attachment #2: Type: text/html, Size: 2639 bytes --]

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Lars Magne Ingebrigtsen]

Bozhidar Batsov <bozhidar@batsov.com> writes:

> 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

`mapconcat'

> * string-trim/string-trim-left/string-trim-right

Perhaps.

> * string-chop

`split-string'

> * string-chomp

What does that do?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

On 22 November 2013 12:15, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Bozhidar Batsov <bozhidar@batsov.com> writes:
>
> > 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
>
> `mapconcat'
>

You can't really favour this:

(mapconcat 'identity '(s1 s2 s3) separator)

over:

(defun string-join (separator &rest strings)
  (mapconcat 'identity strings separator))

(string-join separator s1 s2 s3)


>
> > * string-trim/string-trim-left/string-trim-right
>
> Perhaps.
>
> > * string-chop
>
> `split-string'
>

I'm not sure what split-string has to do with this?

From Ruby's API docs (
http://www.ruby-doc.org/core-1.9.3/String.html#method-i-chop):

Returns a new String with the last character removed. If the string ends
with \r\n, both characters are removed. Applying chop to an empty string
returns an empty string.String#chomp is often a safer alternative, as it
leaves the string unchanged if it doesn’t end in a record separator.

It's available in most scripting languages.


>
> > * string-chomp
>
> What does that do?
>

"hello".chomp            #=> "hello"
"hello\n".chomp          #=> "hello"
"hello\r\n".chomp        #=> "hello"
"hello\n\r".chomp        #=> "hello\n"
"hello\r".chomp          #=> "hello"
"hello \n there".chomp   #=> "hello \n there"
"hello".chomp("llo")     #=> "he"

It's origin is Perl, but it's available in most scripting languages.


>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 3557 bytes --]

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Stefan Monnier]

> You can't really favour this:
>   (mapconcat #'identity (list s1 s2 s3) separator)
> over:
>   (string-join separator s1 s2 s3)

I'm not sure if one is clearly superior to the other.  But having one,
there's not much motivation to add the other.  But `string-join' can
definitely be added to the new helpers.el.

>> > * string-trim/string-trim-left/string-trim-right
>> Perhaps.

These also would be good candidates for helpers.el.

>> > * string-chop

I can't remember using something similar to string-chop.  In Perl, this
was handy because it's frequent to receive "a line with a terminating
LF", but in Emacs it doesn't seem to happen nearly as often.


        Stefan

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

Stefan, should I also add `string-suffix-p' to helpers.el?


On 22 November 2013 16:07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > You can't really favour this:
> >   (mapconcat #'identity (list s1 s2 s3) separator)
> > over:
> >   (string-join separator s1 s2 s3)
>
> I'm not sure if one is clearly superior to the other.  But having one,
> there's not much motivation to add the other.  But `string-join' can
> definitely be added to the new helpers.el.
>
> >> > * string-trim/string-trim-left/string-trim-right
> >> Perhaps.
>
> These also would be good candidates for helpers.el.
>
> >> > * string-chop
>
> I can't remember using something similar to string-chop.  In Perl, this
> was handy because it's frequent to receive "a line with a terminating
> LF", but in Emacs it doesn't seem to happen nearly as often.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 1419 bytes --]

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Stefan Monnier]

> Stefan, should I also add `string-suffix-p' to helpers.el?

You can add it alongside string-prefix-p.
[ But don't add the aliases you suggested: aliases are only useful to
  preserve backward compatibility and such use-cases where both names are
  necessary.  ]


        Stefan

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Josh]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Nov 22, 2013 6:07 AM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
> >> > * string-chop
>
> I can't remember using something similar to string-chop.  In Perl, this
> was handy because it's frequent to receive "a line with a terminating
> LF", but in Emacs it doesn't seem to happen nearly as often.

I'm guessing you don't use `shell-command-to-string' much.

[-- Attachment #2: Type: text/html, Size: 548 bytes --]

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Stefan Monnier]

>> I can't remember using something similar to string-chop.  In Perl, this
>> was handy because it's frequent to receive "a line with a terminating
>> LF", but in Emacs it doesn't seem to happen nearly as often.
> I'm guessing you don't use `shell-command-to-string' much.

Indeed, it's not used very often (among other things because it
requires using a shell, and hence requires quoting).
But even when it's used, the output is often more than a single line.
I'm not saying we never need to trim a terminating newline, I'm just
saying that it's not a particularly common operation, so that providing
something like string-chop for it doesn't seem very useful.


        Stefan

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > I can't remember using something similar to string-chop.  In Perl, this
 > was handy because it's frequent to receive "a line with a terminating
 > LF", but in Emacs it doesn't seem to happen nearly as often.

That's because Emacs Lisp isn't line-oriented at IO time, and when
parsing lines is needed, it's done with (re-search-forward "^...$"),
which automatically chops (and only when appropriate).

While I'm glad Emacs Lisp permits the style indicated by the request
for these features, I at least don't use it often enough to want them
as standard features in Emacs LIsp.

Steve

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Lars Magne Ingebrigtsen]

Bozhidar Batsov <bozhidar@batsov.com> writes:

> You can't really favour this:
>
> (mapconcat 'identity '(s1 s2 s3) separator)
>
> over:
>
> (defun string-join (separator &rest strings)
> (mapconcat 'identity strings separator))
>
> (string-join separator s1 s2 s3)

Well, that's a very odd use case.

You normally have a list of strings that you want to join.

So it's either

(mapconcat 'identity list separator)

or

(apply 'string-join separator list)

which seems awfully odd.  I agree that getting rid of the function
parameter would sometimes make for tidier code -- at work we have a
(txt:concat* separator list) function which is nice (in Common Lisp),
but it doesn't really seem worth it just to get rid of the function
parameter if you already have mapconcat...

If you have a few strings, then using

(concat s1 " foo " s2 " bar " s2)

seems more a more likely use case.

As for the Perl-ey chop/chomp functions, I can't (off the top of my
head) remember having much use for those functions in Emacs.  And I've
done my share of process/protocol parsing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: [PATCH] * lisp/subr.el (string-suffix-p): New function.

[Jarek Czekalski]

W dniu 2013-11-22 08:06, Bozhidar Batsov pisze:
> No comments == no objections? :-)
>

+1 for your idea of adding several string functions.

I see the following benefits:
1. Improvement of code readability, when using these functions.
2. Easier learning of Elisp, by making string manipulations easier to find.

What stands on the other side? What are the disadvantages of introducing 
Bozhidar's functions as built-ins? I see some opinions that are to 
discourage Bozhidar without giving explicit reasons.

Using "helpers.el" seems to preserve the first advantage, while losing 
the second.

Jarek