From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36392: (info "(elisp)Writing Emacs Primitives") might need some clarifications Date: Wed, 26 Jun 2019 18:14:20 +0300 Message-ID: <831rzgl6pf.fsf@gnu.org> References: <87v9ws8pe8.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="141632"; mail-complaints-to="usenet@blaine.gmane.org" Cc: stefan@marxist.se, 36392@debbugs.gnu.org To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 26 17:15:27 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hg9du-000ahM-3h for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Jun 2019 17:15:26 +0200 Original-Received: from localhost ([::1]:40996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hg9dt-0000re-4W for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Jun 2019 11:15:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40278) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hg9dd-0000ny-Bt for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 11:15:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hg9dZ-0003yo-L5 for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 11:15:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51494) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hg9dW-0003v4-Ju for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 11:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hg9dW-0004CC-Dx for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2019 11:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Jun 2019 15:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36392 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 36392-submit@debbugs.gnu.org id=B36392.156156209916109 (code B ref 36392); Wed, 26 Jun 2019 15:15:02 +0000 Original-Received: (at 36392) by debbugs.gnu.org; 26 Jun 2019 15:14:59 +0000 Original-Received: from localhost ([127.0.0.1]:36804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hg9dQ-0004Be-4u for submit@debbugs.gnu.org; Wed, 26 Jun 2019 11:14:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hg9dK-0004BN-V4 for 36392@debbugs.gnu.org; Wed, 26 Jun 2019 11:14:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hg9dA-0003bv-87; Wed, 26 Jun 2019 11:14:42 -0400 Original-Received: from [176.228.60.248] (port=2534 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hg9d7-0000DL-VJ; Wed, 26 Jun 2019 11:14:39 -0400 In-reply-to: <87v9ws8pe8.fsf@tcd.ie> (contovob@tcd.ie) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:161513 Archived-At: > From: "Basil L. Contovounesios" > Date: Wed, 26 Jun 2019 14:09:03 +0100 > Cc: 36392@debbugs.gnu.org > > >From 3d85d73858fe0c126277d04db8b99eeb9f09d672 Mon Sep 17 00:00:00 2001 > From: "Basil L. Contovounesios" > Date: Wed, 26 Jun 2019 13:05:51 +0100 > Subject: [PATCH] Clarify & update (elisp) Writing Emacs Primitives > > * doc/lispref/internals.texi (Writing Emacs Primitives): Replace > outdated For listing with current Fwhile, so that the subsequent > paragraph on maybe_quit still applies. Reconcile other code > listings with their current source. Fix indentation of sample DEFUN > argument lists. Replace ... with @dots{}. Fix argument list of > Ffoo example. Describe UNEVALLED special forms as taking a single > argument. (bug#36392) Hmm... I admit that I don't understand the rationale for these changes. Why replace the example? It's a useful example, and I see nothing wrong with it per se. The actual code doesn't have maybe_quit anymore, but so what? I don't think we should chace every change in the sources with our examples in the manual. > @@ -863,20 +860,23 @@ Writing Emacs Primitives > arguments, there must be one C argument for each Lisp argument, and > each argument must be of type @code{Lisp_Object}. (Various macros and > functions for creating values of type @code{Lisp_Object} are declared > -in the file @file{lisp.h}.) If the primitive has no upper limit on > -the number of Lisp arguments, it must have exactly two C arguments: > -the first is the number of Lisp arguments, and the second is the > -address of a block containing their values. These have types > -@code{int} and @w{@code{Lisp_Object *}} respectively. Since > -@code{Lisp_Object} can hold any Lisp object of any data type, you > -can determine the actual data type only at run time; so if you want > -a primitive to accept only a certain type of argument, you must check > -the type explicitly using a suitable predicate (@pxref{Type Predicates}). > +in the file @file{lisp.h}.) If the primitive is a special form, it > +must accept a Lisp list containing its unevaluated Lisp arguments as a > +single argument of type @code{Lisp_Object}. If the primitive has no > +upper limit on the number of evaluated Lisp arguments, it must have > +exactly two C arguments: the first is the number of Lisp arguments, > +and the second is the address of a block containing their values. > +These have types @code{ptrdiff_t} and @w{@code{Lisp_Object *}}, > +respectively. Since @code{Lisp_Object} can hold any Lisp object of > +any data type, you can determine the actual data type only at run > +time; so if you want a primitive to accept only a certain type of > +argument, you must check the type explicitly using a suitable > +predicate (@pxref{Type Predicates}). > @cindex type checking internals This part sounds OK to me, and is probably more than enough to fix the issue at hand. > - case ON_NOTHING: /* NOT in window at all. */ > + case ON_NOTHING: This seems a change for the worst? > > 2. "Although the garbage collector does not reclaim objects reachable > > from C ‘Lisp_Object’ stack variables, it may move non-object > > components of an object, such as string contents; so functions > > that access non-object components must take care to refetch their > > addresses after performing Lisp evaluation." > > > > I don't think this is very clear. What is non-object components? How > > would I refetch their addresses? How is this relevant to the topic at > > hand? > > I don't know about this. I clarified that. Thanks.