RE: split-string bug in CVS tip of Emacs

[Peter Milliken <PeterM@resmed.com.au>]

Miles, thanks again for the reference.

Just read the thread - there seems to have been some attempt at representing
the "third party package" people such as myself but it seemed to devolve to
"well, we'll be nice guys and send them a patch" - which is pretty
irrelevant in my opinion :-) How did "you" (not you personally Miles, but
"you" the developers list) intend to get the patch to any users of my
package? Of course they wouldn't necessarily have taken up the next release
of Emacs and so the "bug" would have been a time bomb waiting to explode in
each users face as they attempted to use the (now) broken functionality.
Unfortunately I don't maintain a registry of users that I can "push" the
change too.

The problem entered the Emacs development stream sometime between 21.1 and
21.3 - but I wrote this (broken now) portion of code for 21.3 (maybe even
21.2 - I can't remember exactly).

I can fix it myself (the original code was very fuzzy anyway - but often
when you are coding off the top of your head then you do what works and
worry about doing it "properly" later - if there is a later!)

I don't see any easy answer - a personal preference would have been to
modify split-string so it was Emacs/XEmacs independent i.e. it didn't break
my code! :-) But then you could potentially end up with code that said if
XEmacs then else if Emacs then etc - not nice :-)

Is there some list somewhere that I can subscribe to that talks *only* about
proposed changes to existing Elisp definitions? So I can be aware earlier of
something like this? (I am only involved now with the CVS tip because I was
desparate to gain subversion compatibility - otherwise I would have been
blissfully unaware of the issue until the next version of Emacs was released
and users of my package came complaining). I am already subscribed to the
developer list - but that has way too much traffic about fixes etc for me to
filter/read for Elisp definition changes such as this one. 

I wonder whether there is any other "gotcha's" waiting around the corner for
me in this next version of Emacs............. To quote an advertisement
running here in NSW - "not happy Jan, not happy at all!" :-) But that's
life, you get what you pay for....

Peter

> -----Original Message-----
> From: Miles Bader [mailto:miles@gnu.org]
> Sent: Thursday, September 16, 2004 10:32 PM
> To: Peter Milliken
> Cc: 'rms@gnu.org'; bug-gnu-emacs@gnu.org
> Subject: Re: split-string bug in CVS tip of Emacs
> 
> 
> Peter Milliken <PeterM@resmed.com.au> writes:
> > Just out of curiosity, is there any particular reason for 
> breaking backward
> > compatibility like this?
> 
> My vaaaaague memory is that it was for compatibility with xemacs.
> The new definition _does_ omit null entries by default when a 
> nil split
> regexp (=> whitespace) is used, and I think it was judged that this
> would cover the great bulk of compatibility problems.
> 
> Hmmm, google reveals this:
> 
>    http://lists.gnu.org/archive/html/emacs-devel/2003-04/msg00472.html
> 
> It's a very long thread, and probably covers most questions 
> you'd have.
> 
> -Miles
> -- 
> I'm beginning to think that life is just one long Yoko Ono 
> album; no rhyme
> or reason, just a lot of incoherent shrieks and then it's 
> over.  --Ian Wolff
> 


Warning:  Copyright ResMed.  Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient.
 
This communication is confidential and may contain legally privileged information.
By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal
privilege in,the content of the email and of any attachments.
If the recipient of this message is not the intended addressee, please call ResMed immediately on  +61 2 9886 5000 Sydney, Australia.