[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rationale for split-string?

From: Jerry James
Subject: Re: Rationale for split-string?
Date: 21 Apr 2003 23:09:31 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code)

Luc Teirlinck <address@hidden> wrote:
> First of all, I am not worried about Stephen's formulation being
> unnatural (although the original formulation actually would produce
> unnatural results in the default case), but about it breaking existing
> code.


> The "however" is that we are not defining a *new* function but
> *re*defining an *existing* function, an often used and extremely
> general existing function.  That is all but guaranteed to produce a
> wild variety of bugs.

Speaking of existing code, it's worth making a couple more points.  It
appears to me that Emacs 21.1 contained a version with the same behavior
as XEmacs'; that is, it produced empty strings at the beginning and end
in the cases of interest.  Emacs 21.4 contained the current version,
that discards such empty strings.  So did anybody on the Emacs team
worry about breaking existing code when 21.4 was released, nearly 4
years ago?  If so, what steps were taken to counter such breakage?  Did
"a wild variety of bugs" appear at the time?  Are there any mail
archives of emacs-devel available from back then?

Furthermore, how much code will just work, whether the empty strings are
present or not?  After all, Emacs' current implementation can still
produce results containing empty strings, and doesn't even live up to
its docstring's promise of not having any at the beginning or end, as
some of Stephen's examples show, so any split-string clients still have
to deal with such strings.  How much code uses the delete idiom to throw
the empty strings away?  That code wouldn't notice the change.

I did a lot of digging through the XEmacs package code a little while
ago while researching this issue.  I didn't see any code that
conditionalized on the version of split-string (although I did not make
a complete tour, either), so I suspect that a lot of code still assumes
the semantics of the old version, and just never noticed that some empty
strings don't appear any more.

In short, is there any reason to believe that it wouldn't break LESS
code to revert to the old version and pretend that the last 4 years
never happened?
Jerry James

reply via email to

[Prev in Thread] Current Thread [Next in Thread]