From xemacs-m  Sun May 11 15:50:19 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id PAA04098
	for <xemacs-beta@xemacs.org>; Sun, 11 May 1997 15:50:18 -0500 (CDT)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.5/8.8.5) id NAA16568;
	Sun, 11 May 1997 13:51:39 -0700
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Re: Fixing C-g; zmacs-region woes
References: <199705021924.OAA22675@xemacs.org>
X-Url: http://www.miranova.com/%7Esteve/
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@calag.com>
In-Reply-To: Chuck Thompson's message of Fri, 02 May 1997 14:24:48 -0500
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/mixed;
 boundary="Multipart_Sun_May_11_13:51:37_1997-1"
Content-Transfer-Encoding: 7bit
Date: 11 May 1997 13:51:37 -0700
Message-ID: <m2pvuxu3za.fsf@altair.xemacs.org>
Lines: 66
X-Mailer: Gnus v5.4.52/XEmacs 20.2

--Multipart_Sun_May_11_13:51:37_1997-1
Content-Type: text/plain; charset=US-ASCII

(Revisiting the extra buffer argument issue in the C source code)

Chuck Thompson <cthomp@xemacs.org> writes:

> Iff he has a point that is applicable to XEmacs.  Would someone please
> post what RMS has said so it can be discussed?  Obviously there a
> number of us who think changing this back would be a big mistake.

O.K.  I did find a message from him listing his arguments.  I'm still
unclear on exactly what Martin was intending, so perhaps he can
enlighten us as well.
-- 
steve@calag.com baur
Unsolicited commercial e-mail will be billed at $250/message.

--Multipart_Sun_May_11_13:51:37_1997-1
Content-Type: message/rfc822

X-From-Line: rms@gnu.ai.mit.edu  Mon Feb 17 20:29:11 1997
Return-Path: <rms@gnu.ai.mit.edu>
Received: from psilocin.gnu.ai.mit.edu (rms@psilocin.gnu.ai.mit.edu [128.52.46.62])
	by deanna.miranova.com (8.8.5/8.8.5) with SMTP id UAA11895
	for <steve@miranova.com>; Mon, 17 Feb 1997 20:29:02 -0800
Received: by psilocin.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id XAA11568; Mon, 17 Feb 1997 23:29:46 -0500
Date: Mon, 17 Feb 1997 23:29:46 -0500
Message-Id: <199702180429.XAA11568@psilocin.gnu.ai.mit.edu>
From: Richard Stallman <rms@gnu.ai.mit.edu>
To: steve@miranova.com
In-reply-to: <m220ai9utf.fsf@altair.xemacs.org> (message from Steven L Baur on
	15 Feb 1997 03:23:40 -0800)
Subject: Re: optional buffer arguments vs with-current-buffer
Reply-to: rms@gnu.ai.mit.edu
References: <199702111000.FAA06405@psilocin.gnu.ai.mit.edu> <m220ai9utf.fsf@altair.xemacs.org>
Xref: altair.xemacs.org xemacs-19.15-todo:92
Lines: 26

    Emotionally, I don't care one way or the other.  It does not appear to
    be a heavily-used feature by us in any event.  with-current-buffer has
    the advantage of being analogous to existing constructs.  Is that how
    you wish to solve this problem?

I think that with-current-buffer is a cleaner method to use.  For this
reason, I wouldn't implement optional buffer args.  However, whether
to implement them isn't the question now.

The reason I think it is better to get rid of those optional
arguments, than to keep them, is the fact that they are supposed to be
"last".  The idea that the user can remember "the buffer is the last
arg" was supposed to make a global scheme that is simple to remember
and thus a good interface.

But we cannot expect these args to remain last!  New arguments need to
get added from time to time.  If the 4th arg is last today, it won't
be last when a 5th arg is added.

In the long run, users will have to remember a long list such as "The
buffer is the 4th arg in foo, the 2nd in bar, the 5th in foobar, ...."
with dozens of cases.  That makes the interface an impediment rather 
than a clean global scheme.

with-current-buffer is much easier to remember.

--Multipart_Sun_May_11_13:51:37_1997-1--

