From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Goel Newsgroups: gmane.emacs.devel Subject: Re: Fixing numerous `message' bugs.. Date: Thu, 06 Dec 2007 09:36:21 -0500 Message-ID: <87ve7b6gbe.fsf@marie.gnufans.net> References: <87myso8yrs.fsf@marie.gnufans.net> <85sl2gqeg6.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1196951831 27334 80.91.229.12 (6 Dec 2007 14:37:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2007 14:37:11 +0000 (UTC) Cc: Dave Goel , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 06 15:37:20 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J0Hqi-0001gb-JQ for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2007 15:37:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0HqR-0005WR-P4 for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2007 09:36:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J0HqM-0005Sm-2h for emacs-devel@gnu.org; Thu, 06 Dec 2007 09:36:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J0HqJ-0005Mb-2g for emacs-devel@gnu.org; Thu, 06 Dec 2007 09:36:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J0HqI-0005MB-Px for emacs-devel@gnu.org; Thu, 06 Dec 2007 09:36:46 -0500 Original-Received: from mtao01.charter.net ([209.225.8.186]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J0HqC-00013r-Kx; Thu, 06 Dec 2007 09:36:40 -0500 Original-Received: from aarprv02.charter.net ([10.20.200.72]) by mtao01.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20071206143627.MNIR2237.mtao01.charter.net@aarprv02.charter.net>; Thu, 6 Dec 2007 09:36:27 -0500 Original-Received: from marie.gnufans.net ([66.168.196.121]) by aarprv02.charter.net with ESMTP id <20071206143627.WTAF495.aarprv02.charter.net@marie.gnufans.net>; Thu, 6 Dec 2007 09:36:27 -0500 Original-Received: from deego by marie.gnufans.net with local (Exim 3.36 #1 (Debian)) id 1J0Hpu-0007uO-00; Thu, 06 Dec 2007 09:36:22 -0500 X-Face: #5@=vrmx5t3mZaPY8(mR.n+V#:%4NW7j5A&^}@lGp2rK; CQ4%iH1v'gh/^A)w5*6c&R2(P' 4+seYDq8OK'LPI/C(C^A*w|f*t+8, 'T8b#_0~h3!A7GoVroE[cr0Fb'A0%SdU|Lk@gBV&1vA In-Reply-To: <85sl2gqeg6.fsf@lola.goethe.zz> (David Kastrup's message of "Thu, 06 Dec 2007 11:56:25 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Chzlrs: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:84790 Archived-At: David Kastrup writes: > D. Goel writes: >> >> (let ((arg ((rest-of-the-code)))) >> (if (null arg) >> (message nil) >> (message "%s" arg))) > > (message (unless foo (if bar "abc" "def%s")) filename) This alternative fix relies on going deep inside developer's "rest-of-the-code". This is a wrong solution. What will you do if that rest-of-the-code relies on strings constructed in other functions? (That is just a simple example. Emacs is full of very creative codes, constructed in macros and many other beautiful things, and strings read from assoc lists...) Change the code in those other functions? What if the other functions are used elsewhere? To be safe, I should perhaps duplicate the 10000-char assoc-list into an assoc-list-called-by-message and make your fix there? Rather than duplicate many such solutions and add thousands of lines of code, isn't it easier to add one small function `msg'? Even otherwise, the (let ((arg "rest-of-the-code"..))) solution itself would add a lot of extra verbiage, much more so than a simple function `msg'. This is also an impractical solution, (a) My semi-automated code-fixers cannot handle this. (b) This involves a lot of studying of code. I mentioned these bugs in calls to `message' and `error' were identified probably more than a year ago; I have fixed a lot of these bugs, but something like 90% of these bugs remain unfixed... the problem was so bad that edebug itself had these bugs, so that edebugging itself broke mysteriously at times. If I can introduce (msg), I can fix all these bugs right now. > Note that it is perfectly fine to have spurious trailing arguments to > message. sure. > > (defun msg (arg) > (message (and arg "%s") arg)) nice. > and then it is simple enough that it is not worth bothering introducing > a separate function. No, it isn't. You identify the problem below yourself. > Of course, arg should not involve a complex calculation. And, of course, they do. They also involve calls to other functions, etc. > >> .. this new function can be further improved to be more general, so >> that develepors can simply start preferring the new msg if they like - >> >> (defun msg (&rest args) >> (cond >> ((null args) (message nil)) >> ((null (car args)) (message nil)) >> ((= (length args) 1) (message "%s" (car args))) >> (apply 'message args))) > > I think that is nonsensical. Problems occur only when a message > contains non-fixed material Yeah, which is the case a lot of those times. And, that is the problem. > (which may or may not contain percentages), but a message will > pretty much never contain _exclusively_ non-fixed material. huh? > So a good solution will almost always involve more than a trivial > "%s" format. If you really want something more than %s, say, %% [1], no one stops you from still using message correctly, as follows: (message "%%") or even (msg (format "%%")) Most of the time a developer calls (message), he calls it with one arg, and he already pre-formats his arg. Almost always when the developer calls (message) with one arg, he is actually looking for (msg)[2]. And, if he isn't, he is still welcome to use (message) the correct way. [1] though I assure you, each of the thousand times I have seen a (message) bug, the developer has always meant that "trivial" %s. [2] Once again, in the thousands of cases I have examined, nowhere have I seen (message) called with just one non-nil argument, where (message "%s" arg) fails to do what the developer wanted. --- Please note that I am *not* saying I want to replace every call to (message) in the source code with (msg). *Only* the buggy calls; and only when I have verified carefully that (msg) works correctly for the code at hand.