split-string behavior change

split-string behavior change

[Drew Adams]

I'm not suggesting we change anything now, but I'm curious about the change
in behavior of split-string from Emacs 21 to 22.

Emacs 20, 21: (split-string "abc" "") gives ("a" "b" "c")

Emacs 22: (split-string "abc" "")   gives ("" "a" "b" "c" "")
     and: (split-string "abc" "" t) gives ("a" "b" "c")

IOW, we added an optional third arg, for which the non-nil value - not the
nil value, gives the same result as before. And using the same code as
before, with no third arg, now gives a different result (breaks).

That seems backward, to me. Why wasn't the polarity of the new OMIT-NULLS
arg reversed (and so called INCLUDE-NULLS)?

If this change was a mistake, so be it. But if it was conscious decision and
not a mistake, then I'm curious to know the reason for it.

Re: split-string behavior change

[Nick Roberts]

 > IOW, we added an optional third arg, for which the non-nil value - not the
 > nil value, gives the same result as before. And using the same code as
 > before, with no third arg, now gives a different result (breaks).
 > 
 > That seems backward, to me. Why wasn't the polarity of the new OMIT-NULLS
 > arg reversed (and so called INCLUDE-NULLS)?
 >
 > If this change was a mistake, so be it. But if it was conscious decision and
 > not a mistake, then I'm curious to know the reason for it.

Have you looked at the archives or tried googling with split-string and
omit-nulls?

The latter gives me

http://osdir.com/ml/emacs.xemacs.design/2003-04/msg00142.html

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: split-string behavior change

[Drew Adams]

> Have you looked at the archives or tried googling with 
> split-string and omit-nulls?
> 
> The latter gives me
> 
> http://osdir.com/ml/emacs.xemacs.design/2003-04/msg00142.html

Thanks, I should have thought of that.

That was a long and winding thread, full of reasoning about
incompatibilities between XEmacs and GNU Emacs and mentioning a GNU Emacs
change in Emacs 20.1 and back again in 20.4 (and now back again ++ in 22).
Quite a mess.

I still didn't get a good sense for why GNU Emacs 22 should break Emacs 20
and 21 compatible code this way, but I guess it's water under the bridge.
Seems like it was some sort of unhappy compromise all around.

Anyway, it was an interesting read; thanks.

split-string behavior change

[Stephen J. Turnbull]

Drew Adams writes:

 > I'm not suggesting we change anything now, but I'm curious about the change
 > in behavior of split-string from Emacs 21 to 22.

split-string in Emacs 21 was unable to give appropriate results for

    (split-string csv ",")

where CSV is in comma-separated values format, and has leading or
trailing empty fields.  That turns out to be a moderately big deal,
because it is non-trivial to code this function efficiently and
correctly.  (At least, that was the motivation I was told for XEmacs
not removing nulls at all.  Apparently how to parse CSV correctly was
a FAQ in some circles.)  Also, for several cases it gave different
results from XEmacs (including this case).

The current behavior is the result of a compromise which preserves the
magic behavior of removing empty fields in the one-argument case, uses
the simpler behavior of just splitting on the regexp always in the
two-argument case, and restores magic behavior in the three argument
case with a non-nil third argument.

RE: split-string behavior change

[Drew Adams]

>  > I'm not suggesting we change anything now, but I'm curious 
>  > about the change in behavior of split-string from Emacs 21 to 22.
> 
> split-string in Emacs 21 was unable to give appropriate results for
> 
>     (split-string csv ",")
> 
> where CSV is in comma-separated values format, and has leading or
> trailing empty fields.  That turns out to be a moderately big deal,
> because it is non-trivial to code this function efficiently and
> correctly.  (At least, that was the motivation I was told for XEmacs
> not removing nulls at all.  Apparently how to parse CSV correctly was
> a FAQ in some circles.)  Also, for several cases it gave different
> results from XEmacs (including this case).
> 
> The current behavior is the result of a compromise which preserves the
> magic behavior of removing empty fields in the one-argument case, uses
> the simpler behavior of just splitting on the regexp always in the
> two-argument case, and restores magic behavior in the three argument
> case with a non-nil third argument.

Thanks for the summary. 

I was questioning only the polarity of the optional third arg - why a nil
value wasn't used to give you the same behavior for two args in Emacs 20,
21, and 22. I understand now that using non-nil was a negotiated compromise.