From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Jerry James Newsgroups: gmane.emacs.xemacs.design,gmane.emacs.devel Subject: Re: Rationale for split-string? Date: 21 Apr 2003 23:09:31 -0500 Sender: xemacs-design-admin@xemacs.org Message-ID: References: <87brz57at2.fsf@tleepslib.sk.tsukuba.ac.jp> <200304171744.h3HHiJCx009215@rum.cs.yale.edu> <87adem27ey.fsf@tleepslib.sk.tsukuba.ac.jp> <87ist8yv4n.fsf@tleepslib.sk.tsukuba.ac.jp> <200304212111.h3LLBLK11879@eel.dms.auburn.edu> <20030421234347.GA12507@gnu.org> <200304220326.h3M3Q1912252@eel.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1050984653 14060 80.91.224.249 (22 Apr 2003 04:10:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2003 04:10:53 +0000 (UTC) Cc: emacs-devel@gnu.org, xemacs-design@xemacs.org Original-X-From: xemacs-design-admin@xemacs.org Tue Apr 22 06:10:51 2003 Return-path: Original-Received: from gwyn.tux.org ([199.184.165.135]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 197p6w-0003dy-00 for ; Tue, 22 Apr 2003 06:10:28 +0200 Original-Received: from gwyn.tux.org (localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.11.6p2/8.9.1) with ESMTP id h3M4B2M07254; Tue, 22 Apr 2003 00:11:02 -0400 Original-Received: (from turnbull@localhost) by gwyn.tux.org (8.11.6p2/8.9.1) id h3M4ALj07136 for xemacs-design-mailman@xemacs.org; Tue, 22 Apr 2003 00:10:21 -0400 Original-Received: (from mail@localhost) by gwyn.tux.org (8.11.6p2/8.9.1) id h3M4ABB07103 for turnbull@tux.org; Tue, 22 Apr 2003 00:10:11 -0400 Original-Received: from stephens.ittc.ku.edu (stephens.ittc.ku.edu [129.237.125.220]) by gwyn.tux.org (8.11.6p2/8.9.1) with ESMTP id h3M4AAM07098 for ; Tue, 22 Apr 2003 00:10:11 -0400 Original-Received: from diannao.ittc.ku.edu (diannao.ittc.ku.edu [129.237.126.112]) by stephens.ittc.ku.edu (8.12.9/8.12.9/ITTC-ANTISPAM-ANTIVIRUS-3.0) with ESMTP id h3M49VMR005440; Mon, 21 Apr 2003 23:09:31 -0500 Original-Received: by diannao.ittc.ku.edu (8.11.6/KU-4.0-client) id h3M49VK11319; Mon, 21 Apr 2003 23:09:31 -0500 Original-To: Luc Teirlinck In-Reply-To: <200304220326.h3M3Q1912252@eel.dms.auburn.edu> Original-Lines: 44 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Portable Code) X-VirusScan: Clean X-XEmacs-List: design Errors-To: xemacs-design-admin@xemacs.org X-BeenThere: xemacs-design@xemacs.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of design and features for XEmacs. List-Unsubscribe: , Xref: main.gmane.org gmane.emacs.xemacs.design:2091 gmane.emacs.devel:13340 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13340 Luc Teirlinck 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/