bug-gnu-emacs
[Top][All Lists]
Advanced

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

RE: split-string bug in CVS tip of Emacs


From: Peter Milliken
Subject: RE: split-string bug in CVS tip of Emacs
Date: Fri, 17 Sep 2004 07:03:29 +1000

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.





reply via email to

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