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));
next prev parent 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.