split-string bug in CVS tip of Emacs

split-string bug in CVS tip of Emacs

[Peter Milliken]

I have taken to downloading the nightly tarball of the Emacs CVS repository
(I cannot download via CVS itself due to firewall restrictions). I have
noticed that some Elisp I use/wrote is failing when running using the CVS
tip versus the 21.3 release. I tracked the problem behaviour to split-string
in subr.el

The Elisp Manual (21-2.8) states (in part):

     When there is a match adjacent to the beginning or end of the
     string, this does not cause a null string to appear at the
     beginning or end of the list:

          (split-string "out to moo" "o+")
          => ("ut t" " m")

But using the CVS tip of Emacs I am getting this:

          (split-string "out to moo" "o+")
          => ("" "ut t" " m" "")

              ^
              |- this leading null string should not be there according to
Elisp 21-2.8 manual.


Is this a deliberate change to the behaviour of Emacs or is it a bug? i.e. I
was unable to "locate" the current Elisp manual in the repository - lack of
knowing what to search for I guess :-), so I was unable to check the latest
requirements on split-string.

Thanks
Peter

Peter Milliken
Software Engineer
ResMed
Phone: +61 2 9886-5059
Fax:   +61 2 9878-5564 


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.

Re: split-string bug in CVS tip of Emacs

[Stefan Monnier]

> The Elisp Manual (21-2.8) states (in part):

>      When there is a match adjacent to the beginning or end of the
>      string, this does not cause a null string to appear at the
>      beginning or end of the list:

>           (split-string "out to moo" "o+")
>           => ("ut t" " m")

> But using the CVS tip of Emacs I am getting this:

>           (split-string "out to moo" "o+")
>           => ("" "ut t" " m" "")

>               ^
>               |- this leading null string should not be there according to
> Elisp 21-2.8 manual.

Check the etc/NEWS file.  It says something about this change.

> Is this a deliberate change to the behaviour of Emacs or is it a bug? i.e. I
> was unable to "locate" the current Elisp manual in the repository - lack of
> knowing what to search for I guess :-), so I was unable to check the latest
> requirements on split-string.

The Elisp manual is now part of the tarball (the source is in directory
`lispref'), so you should just do: C-h i m elisp RET and that should be it.
It may be that the part of the manual hasn't been updated yet.  Updating the
manual is one of the main things that's currently delaying the beginning of
the beta-test phase, so if you can help us with that, it would be great.


        Stefan

split-string bug in CVS tip of Emacs

[Luc Teirlinck]

Stefan Monnier wrote:

    It may be that the part of the manual hasn't been updated yet.

It has been updated with respect to `split-string'.

Sincerely,

Luc.

Re: split-string bug in CVS tip of Emacs

[Richard Stallman]

split-string's behavior has been changed, and the manual has been
updated too in the development sources.

RE: split-string bug in CVS tip of Emacs

[Peter Milliken]

Just out of curiosity, is there any particular reason for breaking backward
compatibility like this?

I am going to have to code around the changed behaviour now so my
application can maintain backward compatibility with earlier versions of
Emacs.

> -----Original Message-----
> From: Richard Stallman [mailto:rms@gnu.org]
> Sent: Wednesday, September 15, 2004 7:32 PM
> To: Peter Milliken
> Cc: bug-gnu-emacs@gnu.org
> Subject: Re: split-string bug in CVS tip of Emacs
> 
> 
> split-string's behavior has been changed, and the manual has been
> updated too in the development sources.
> 


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.

Re: split-string bug in CVS tip of Emacs

[Miles Bader]

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

RE: split-string bug in CVS tip of Emacs

[Peter Milliken]

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.

Re: split-string bug in CVS tip of Emacs

[Stefan Monnier]

> 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

Checking the etc/NEWS file every once in a while (or maybe do it by reading
the emacs-commit list and filtering out anything that's not about etc/NEWS)
allows you to know about changes after they've been applied.

For proposed changes, there's only emacs-devel@gnu.org.

Maybe we should setup a emacs-upcoming-news@gnu.org mailing list that only
gets the diffs applied to etc/NEWS and encourage each and every package
maintainer to subscribe to it.  It'd be pretty low-volume.

And if something looks fishy, you can still try to get it fixed (even if
it's already been applied) by bringing it up on the
emacs-devel@gnu.org list.


        Stefan