GNU bug report logs - #17814
24.3.91; better string manipulation in subr-x

Previous Next

Full log

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
Cc: 17814 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#17814: 24.3.91; better string manipulation in subr-x
Date: Tue, 18 Sep 2018 21:37:20 -0400

close 17814
quit

Shigeru Fukaya <shigeru.fukaya <at> gmail.com> writes:

>>The above string-match will fail on a string that has a newline, and the
>>subsequent code will use whatever was the old match-data, resulting in
>>broken behavior.
>
> "." in "\\`[\s\t\n\r]*\\(.*?\\)[\s\t\n\r]*\\'" must be "\\(.\\|\n\\)", sorry.
>
>>Other than that, I don't have any opinion on such changes (I've never
>>heard anyone complain about code size or cpu-time of any of those
>>functions, so I think it largely doesn't matter either way).
>
> Using string-trim-to-right and string-trim-to-left creates unnecessary
> temporary string if both sides need triming may matter, then?
>
> Anyway, I think I'm just sending a small proposal.  I don't care much
> if you throw it away.  Thank you for spending your time.

An optimization similar to the one proposed here was done for
string-trim-to-{left,right} in [1: 1013e0392b].  I think the strim-trim
change isn't worth the extra complexity (especially since it's not even
entirely clear whether it would be faster/smaller), so I'm closing the
bug.

[1: 1013e0392b]: 2018-07-13 11:28:16 -0400
  Tweak subr-x.el substring functions
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1013e0392b78ee0e2199fb51859dc9e939315f9b

Previous Next

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