From xemacs-m  Thu May  1 00:52:21 1997
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id AAA25167
	for <xemacs-beta@xemacs.org>; Thu, 1 May 1997 00:52:20 -0500 (CDT)
Received: from berne.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.8/16.2) id AA183495939; Thu, 1 May 1997 01:52:19 -0400
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
Message-Id: <199705010552.AA183495939@martigny.ai.mit.edu>
Received: by berne.ai.mit.edu
	(1.40.112.8/16.2) id AA239875937; Thu, 1 May 1997 01:52:17 -0400
Date: Thu, 1 May 1997 01:52:17 -0400
To: steve@miranova.com
Cc: xemacs-beta@xemacs.org
In-Reply-To: <m29120qgnx.fsf@altair.xemacs.org> (message from Steven L Baur on
	30 Apr 1997 15:39:30 -0700)
Subject: Re: Optional BUFFER arguments in functions; `with-current-buffer'

Steven L Baur <steve@miranova.com> wrote:
|
| Hrvoje Niksic <hniksic@srce.hr> writes:
| >
| > How hard is it to port `with-current-buffer', anyway.  
| > I might take a look at it.
| 
| If I understand correctly, his implementation involves hacking the
| bytecompiler which is supposed to make it fast.

Even if you support with-current-buffer via a byte-code operation
it will still be MUCH slower than something like

  (buffer-substring start end buffer)

because the former does NOT need to bind all the buffer-local
variables, etc.

Also, there were some good reasons Ben introduced the explicit
buffer args, I think because there were lots of subtle bugs
in the (C?) code due to it not being explicit which buffer certain
commands were operating on ... search the archives to be sure.

I think this issues deserves further discussion.

-Bill Dubuque

