unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jerry James <james@xemacs.org>
Cc: emacs-devel@gnu.org, xemacs-design@xemacs.org
Subject: Re: Rationale for split-string?
Date: 21 Apr 2003 23:09:31 -0500	[thread overview]
Message-ID: <psd6jfyxz8.fsf@diannao.ittc.ku.edu> (raw)
In-Reply-To: <200304220326.h3M3Q1912252@eel.dms.auburn.edu>

Luc Teirlinck <teirllm@dms.auburn.edu> 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.

[snip]

> 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
http://www.ittc.ku.edu/~james/



  reply	other threads:[~2003-04-22  4:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17  9:06 Rationale for split-string? Stephen J. Turnbull
2003-04-17 11:30 ` Stefan Reichör
2003-04-18  1:54   ` Richard Stallman
2003-04-18  2:59     ` Steve Youngs
2003-04-17 17:44 ` Stefan Monnier
2003-04-17 19:32   ` Luc Teirlinck
2003-04-18 11:50   ` Stephen J. Turnbull
2003-04-18 14:17     ` Stefan Monnier
2003-04-19  8:18       ` Stephen J. Turnbull
2003-04-19 13:35     ` Richard Stallman
2003-04-19  4:14   ` Richard Stallman
2003-04-19  8:55     ` Stephen J. Turnbull
2003-04-21  0:59       ` Richard Stallman
2003-04-21  1:55         ` Luc Teirlinck
2003-04-21 10:58         ` Stephen J. Turnbull
2003-04-21 21:11           ` Luc Teirlinck
2003-04-21 23:43             ` Miles Bader
2003-04-22  3:26               ` Luc Teirlinck
2003-04-22  4:09                 ` Jerry James [this message]
2003-04-22  8:15                   ` Eli Zaretskii
2003-04-22 13:22                     ` Stephen J. Turnbull
2003-04-22 14:38                       ` Jerry James
2003-04-22 12:56                   ` Luc Teirlinck
2003-04-22 14:56                     ` Jerry James
2003-04-22 15:27                       ` Luc Teirlinck
2003-04-22 13:19                 ` Stephen J. Turnbull
2003-04-22 13:39                   ` Miles Bader
2003-04-22 13:51                   ` Luc Teirlinck
2003-04-22 16:26                   ` Luc Teirlinck
2003-04-23  1:00           ` Richard Stallman
2003-04-23  4:09             ` Stephen J. Turnbull
2003-04-24 23:12               ` Richard Stallman
2003-05-20  1:55               ` Stephen J. Turnbull
2003-05-22 15:00                 ` Kai Großjohann
  -- strict thread matches above, loose matches on Subject: below --
2003-05-20  3:11 Bill Wohler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=psd6jfyxz8.fsf@diannao.ittc.ku.edu \
    --to=james@xemacs.org \
    --cc=emacs-devel@gnu.org \
    --cc=xemacs-design@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).