From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.bugs Subject: bug#12351: 24.1; parse-colon-path turns empty paths into nil Date: Sun, 30 Dec 2012 15:37:16 -0500 Message-ID: References: <83licfjnny.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1356899892 9018 80.91.229.3 (30 Dec 2012 20:38:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Dec 2012 20:38:12 +0000 (UTC) Cc: 12351@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 30 21:38:28 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TpPeJ-0006CC-JT for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Dec 2012 21:38:23 +0100 Original-Received: from localhost ([::1]:47927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpPe4-00067x-Od for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Dec 2012 15:38:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpPdy-00067g-V8 for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 15:38:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TpPds-0005Vu-S3 for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 15:38:02 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpPds-0005Vq-O6 for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 15:37:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TpPew-0004ft-07 for bug-gnu-emacs@gnu.org; Sun, 30 Dec 2012 15:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dave Abrahams Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Dec 2012 20:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12351 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12351-submit@debbugs.gnu.org id=B12351.135689990817919 (code B ref 12351); Sun, 30 Dec 2012 20:39:01 +0000 Original-Received: (at 12351) by debbugs.gnu.org; 30 Dec 2012 20:38:28 +0000 Original-Received: from localhost ([127.0.0.1]:37297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TpPeN-0004ey-Fc for submit@debbugs.gnu.org; Sun, 30 Dec 2012 15:38:27 -0500 Original-Received: from mail-vb0-f44.google.com ([209.85.212.44]:63214) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TpPeK-0004eq-Gl for 12351@debbugs.gnu.org; Sun, 30 Dec 2012 15:38:26 -0500 Original-Received: by mail-vb0-f44.google.com with SMTP id fc26so12270174vbb.17 for <12351@debbugs.gnu.org>; Sun, 30 Dec 2012 12:37:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type:x-gm-message-state; bh=mI129jQ/mO8+zjmIrwDsqM8L06JPq6qDudrPaycM64E=; b=E02RMZz1MCexoLzEUT3oDEa7VAR9AFcsrWY1VsAOjwodg8sATd4NGOnqO5EURniedp A5cBKLzgKN1DeqQCAlx8LRoJcRXXkvTk7OVkrHR2p96vV7ZAZKJfLcWSKHbxZBr0dAbN O5ufng6p5RR15+Y/SgTMIGYJOQeQl2rj/b//+/mYHwgw+RYkPLOSEUytfXQP0hdD7chW CzXI4lhUuOE4booHdlc9ttj28kqT3E2F9Zot6ReNbOEkv7mRXCkmyJHjPiJeFQfAXslN PgBJP3O2DECXt3TU38Yxtet7Tzd7KWBvyxT/oP0RPCa7DwV+gx2o5kJvLadZ/g7cMyHO 0Rrg== X-Received: by 10.58.198.164 with SMTP id jd4mr62975452vec.34.1356899838240; Sun, 30 Dec 2012 12:37:18 -0800 (PST) Original-Received: from pluto.boostpro.com (207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com. [207.172.223.249]) by mx.google.com with ESMTPS id z20sm36441823vds.12.2012.12.30.12.37.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Dec 2012 12:37:17 -0800 (PST) Original-Received: by pluto.boostpro.com (Postfix, from userid 501) id 117719ACBD5; Sun, 30 Dec 2012 15:37:16 -0500 (EST) In-Reply-To: <83licfjnny.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Dec 2012 22:22:09 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (darwin) X-Gm-Message-State: ALoCoQmePoigff9WOkJ8fJ3HID5+ZIhvqZ/5pfw3oqB8jxM9ngQgoK0af1FW+mXUqsrsdQVq0Yt+ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:69201 Archived-At: on Sun Dec 30 2012, Eli Zaretskii wrote: >> From: Dave Abrahams >> Date: Sun, 30 Dec 2012 14:53:44 -0500 >> Cc: 12351@debbugs.gnu.org >> >> > Obviously we need the nils to remain, so I will put them back and just >> > mention that empty elements return nil. It's not worth handling the >> > minor aesthetic annoyance of (nil nil) specially. >> >> FWIW, I disagree. IMO you should at least consider fixing eshell and any >> other things that break because of this change. This discontinuity in >> behavior is not merely aesthetic; it makes parse-colon-path difficult to >> use correctly and leads to hard-to-find bugs in any code that fails to >> account for the possible nils. > > This whole discussion is rather futile, unless the opinions are also > backed up by real-life use cases. Can you tell why the previous > behavior made parse-colon-path difficult to use, and in what > situations? Instead of recording that complex situation when I encountered the bug I helpfully (!) recorded a reduced reproducible example that stripped away the use case, which I didn't remember... but I even went the extra mile to reconstruct it. For example, look at http://edward.oconnor.cx/elisp/osx-plist.el The following function is buggy because of the original bug: --8<---------------cut here---------------start------------->8--- (defun osx-plist-update-exec-path () "Update `exec-path' from the PATH environment variable." (let ((path (getenv "PATH"))) (mapc (lambda (dir) (add-to-list 'exec-path dir)) (parse-colon-path path))) exec-path) --8<---------------cut here---------------end--------------->8--- I had to replace it in my local installation as follows: --8<---------------cut here---------------start------------->8--- (defun osx-plist-update-exec-path () "Update `exec-path' from the PATH environment variable." (let ((path (delq nil (parse-colon-path (getenv "PATH"))))) (setq exec-path (dolist (dir exec-path path) (add-to-list 'path (file-name-as-directory dir) :append))))) --8<---------------cut here---------------end--------------->8--- If you go looking for instances of parse-colon-path I'm sure you'll find hundreds of other places where the use was tailored to the documented behavior of parse-colon-path rather than the specific oddball behavior that was actually implemented. I found at least one in my own code just now. IMO, though, you should actually be able to understand this one without any examples. Any discontinuity in behavior means the client needs to write special-case code to handle that special-case behavior. For one or two clients it may be that the special-case behavior matches just what they need, but in general that's highly unlikely. Combine this with the fact that the uniform behavior has been documented for years, and that the inputs that trigger the non-uniformity are rare, and you can be pretty confident that more code has been written to the uniform specification. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost