all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Stefan Merten <smerten@oekonux.de>
Cc: Christian Ohler <ohler@gnu.org>, emacs-devel@gnu.org
Subject: Re: Running ert tests on buffers in rst.el and elsewhere
Date: Tue, 19 Jun 2012 14:06:53 -0400	[thread overview]
Message-ID: <jwvhau7kxg0.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <6280.1340054412@theowa.merten-home.homelinux.org> (Stefan Merten's message of "Mon, 18 Jun 2012 23:20:12 +0200")

> I wanted to test functions which operate on buffers - i.e. use buffer
> content as input and possibly modify the buffer. Buffer includes point
> and mark in this case. Since I found no support for this requirement
> in the ert package I wrote some support code for it. I just polished
> it a bit to better fit into Emacs standards.

Sounds OK.  The code looks mostly OK, except:
- It should either use (require 'cl-lib) or (eval-when-compile (require 'cl)).
- You can use the "--" convention for internal functions/variables
  (e.g. use ert--equal-buffer instead of ert-equal-buffer-internal).
- ert-Buf-create-string could probably use car-less-than-car if a speed
  boost is needed (probably not worth the trouble, tho).
- the docstrings talk about "run list FOO" which is meaningless to me
  (a list can't be run).  So describe FUNCALL a bit better (e.g. making
  it clear that it's expected to have the shape (FUN . ARGS)).
  BTW, instead of (apply (car funcall) (cdr funcall)) you can do
  (apply #'funcall funcall) or
  even (apply #'funcall #'funcall #'funcall funcall) for extra fun.
  Ideally, tho you should be able to just do (apply funcall).
  If interested, the patch below fixes `apply' to accept this use.


        Stefan


=== modified file 'src/eval.c'
--- src/eval.c	2012-06-09 03:14:44 +0000
+++ src/eval.c	2012-06-19 18:02:07 +0000
@@ -2202,7 +2202,7 @@
   return val;
 }
 \f
-DEFUN ("apply", Fapply, Sapply, 2, MANY, 0,
+DEFUN ("apply", Fapply, Sapply, 1, MANY, 0,
        doc: /* Call FUNCTION with our remaining args, using our last arg as list of args.
 Then return the value FUNCTION returns.
 Thus, (apply '+ 1 2 '(3 4)) returns 10.
@@ -2213,11 +2213,10 @@
   EMACS_INT numargs;
   register Lisp_Object spread_arg;
   register Lisp_Object *funcall_args;
-  Lisp_Object fun, retval;
+  Lisp_Object retval;
   struct gcpro gcpro1;
   USE_SAFE_ALLOCA;
 
-  fun = args [0];
   funcall_args = 0;
   spread_arg = args [nargs - 1];
   CHECK_LIST (spread_arg);
@@ -2232,43 +2231,14 @@
       return Ffuncall (nargs, args);
     }
 
-  numargs += nargs - 2;
+  numargs += nargs - 1;
 
-  /* Optimize for no indirection.  */
-  if (SYMBOLP (fun) && !EQ (fun, Qunbound)
-      && (fun = XSYMBOL (fun)->function, SYMBOLP (fun)))
-    fun = indirect_function (fun);
-  if (EQ (fun, Qunbound))
-    {
-      /* Let funcall get the error.  */
-      fun = args[0];
-      goto funcall;
-    }
-
-  if (SUBRP (fun))
-    {
-      if (numargs < XSUBR (fun)->min_args
-	  || (XSUBR (fun)->max_args >= 0 && XSUBR (fun)->max_args < numargs))
-	goto funcall;		/* Let funcall get the error.  */
-      else if (XSUBR (fun)->max_args >= 0 && XSUBR (fun)->max_args > numargs)
-	{
-	  /* Avoid making funcall cons up a yet another new vector of arguments
-	     by explicitly supplying nil's for optional values.  */
-	  SAFE_ALLOCA_LISP (funcall_args, 1 + XSUBR (fun)->max_args);
-	  for (i = numargs; i < XSUBR (fun)->max_args;)
-	    funcall_args[++i] = Qnil;
-	  GCPRO1 (*funcall_args);
-	  gcpro1.nvars = 1 + XSUBR (fun)->max_args;
-	}
-    }
- funcall:
-  /* We add 1 to numargs because funcall_args includes the
-     function itself as well as its arguments.  */
+  /* `numargs' includes the function itself as well as its arguments.  */
   if (!funcall_args)
     {
-      SAFE_ALLOCA_LISP (funcall_args, 1 + numargs);
+      SAFE_ALLOCA_LISP (funcall_args, numargs);
       GCPRO1 (*funcall_args);
-      gcpro1.nvars = 1 + numargs;
+      gcpro1.nvars = numargs;
     }
 
   memcpy (funcall_args, args, nargs * sizeof (Lisp_Object));




  reply	other threads:[~2012-06-19 18:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-18 21:20 Running ert tests on buffers in rst.el and elsewhere Stefan Merten
2012-06-19 18:06 ` Stefan Monnier [this message]
2012-06-25  9:20   ` Stefan Merten
2012-06-22 22:37 ` Christian Ohler
2012-06-25 10:06   ` Stefan Merten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvhau7kxg0.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=ohler@gnu.org \
    --cc=smerten@oekonux.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.