From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lars Brinkhoff Newsgroups: gmane.emacs.devel Subject: User-reserved element in byte code vectors (was: Emacs Common Lisp) Date: 28 Apr 2004 12:43:23 +0200 Organization: nocrew Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <85ad0wfkms.fsf_-_@junk.nocrew.org> References: <85k7036eqr.fsf@junk.nocrew.org> <85smepfzqo.fsf@junk.nocrew.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083150538 1866 80.91.224.253 (28 Apr 2004 11:08:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Apr 2004 11:08:58 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 28 13:08:48 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BImvo-0007oT-00 for ; Wed, 28 Apr 2004 13:08:48 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BImvn-0002oN-00 for ; Wed, 28 Apr 2004 13:08:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BImpL-0004Dm-Lu for emacs-devel@quimby.gnus.org; Wed, 28 Apr 2004 07:02:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BImo4-0004Ad-Fj for emacs-devel@gnu.org; Wed, 28 Apr 2004 07:00:48 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BImnT-00042P-GR for emacs-devel@gnu.org; Wed, 28 Apr 2004 07:00:42 -0400 Original-Received: from [213.242.147.30] (helo=junk.nocrew.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BImXE-00018h-9G; Wed, 28 Apr 2004 06:43:24 -0400 Original-Received: from lars by junk.nocrew.org with local (Exim 3.35 #1 (Debian)) id 1BImXD-0005mB-00; Wed, 28 Apr 2004 12:43:23 +0200 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22294 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22294 [Cc to emacs-devel. Context: It can be useful to store user-defined objects in a byte code vector.] Richard Stallman writes: > The make-byte-code function takes any number of arguments, so it > already works. The problem is that there's no guarantee that future > versions of Emacs won't start to use more than the first six elements. > Now I see the issue. We could decide to leave the 7th element > unused, and document that. Yes, that would be good enough for my purposes. Obviously, when more than one object needs to be stored, I can just put them in a list or a vector and put that in element 7. In my case, I frequently do want to store more than one object, so it would be more efficient if there were more than one element available in the code vector. However, other than extending the above solution to something ugly like "decide to leave the 7th, 8th, and 9th element unused", I don't see a good way to do that. Or maybe... How about defining a variable like this: (defvar byte-code-user-elements 6 "The lowest index of elements in a byte-code object which a user may use. Elements below this index are used by Emacs. Elements including and above this index may be used freely by a user (e.g. by calling make-byte-code); Emacs won't use them for any purpose.") Then future versions of Emacs could raise this limit as needed. -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/