Re: Trimming strings, /emacs/lisp/emacs-lisp/subr-x.el modification

[Jean-Christophe Helary]

> On May 10, 2017, at 0:23, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Michael Heerdegen <address@hidden>
>> Cc: Johan Bockgård <address@hidden>,  address@hidden,
>>  Eli Zaretskii <address@hidden>,  address@hidden,
>>  address@hidden
>> Date: Tue, 09 May 2017 14:05:13 +0200
>> 
>> Jean-Christophe Helary <address@hidden> writes:
>> 
>>>>   (split-string "abc, ;def g,hi" nil nil ",\\|;")
>>>>   =>
>>>>     ("abc" "def" "g")  ; BUG
>>> 
>>> Ok, and the way to get your result is:
>>> 
>>> (split-string "abc, ;def g,hi" nil nil "\\(,\\|;\\)")
>>> 
>>> which means that Emacs thinks it is the caller's duty to provide the
>>> grouping construct, which also happens to be ugly, and non-intuitive
>>> since ",\\|;" is an otherwise valid regexp...
>>> 
>>> So, how do we go about that? Do we report a bug? Or do we find a good
>>> reason for that to happen and modify the documentation for
>>> split-string ?
>> 
>> I'm curious what could be reasons not to fix this (in the code).
>> Allowing only a subset of possible regexps would be quite strange.
>> Would there be any advantages?
> 
> How about if we proceed with the change in string-trim, and file a
> separate bug against both it and split-string, for such regexps?
> These seem to be largely unrelated issues, and it's a pity to block
> Jean-Christophe's changes due to that.

Ok, so we agree that we don't add \\( \\) to the regexp and that we expect the 
caller to send a correct regexp as is the case for split-string, is that 
correct ?

(But I'm  also glad the discussion that started with a trivial modification to 
ns-win.el triggered all that *and* that I understood what was at stake :-)

Jean-Christophe