emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Reimplement module functions


From: Philipp Stephani
Subject: Re: [PATCH] Reimplement module functions
Date: Sun, 14 May 2017 18:08:34 +0000



Eli Zaretskii <address@hidden> schrieb am Sa., 13. Mai 2017 um 19:05 Uhr:
> From: Philipp Stephani <address@hidden>
> Date: Sat, 13 May 2017 16:44:08 +0200
> Cc: Philipp Stephani <address@hidden>
>
> Instead of a lambda, create a new type containing all data required to
> call the function, and support it in the evaluator.  Because this type
> now also needs to store the function documentation, it is too big for
> Lisp_Misc; use a pseudovector instead.  That also has the nice benefit
> that we don't have to add special support to the garbage collector.

Thanks.

> +#ifdef HAVE_MODULES
> +  else if (MODULE_FUNCTIONP (fun))
> +    doc = XMODULE_FUNCTION (fun)->documentation;
> +#endif

I wonder whether it would be cleaner to have MODULE_FUNCTIONP defined
even when HAVE_MODULES is not: it looks like it could save us quite a
few #ifdef's.

Done.
 

> -DEFUN ("internal--module-call", Finternal_module_call, Sinternal_module_call, 1, MANY, 0,
> -       doc: /* Internal function to call a module function.
> -ENVOBJ is a save pointer to a module_fun_env structure.
> -ARGLIST is a list of arguments passed to SUBRPTR.
> -usage: (module-call ENVOBJ &rest ARGLIST)   */)
> -  (ptrdiff_t nargs, Lisp_Object *arglist)
> +Lisp_Object
> +funcall_module (const struct Lisp_Module_Function *const envptr,
> +                ptrdiff_t nargs, Lisp_Object *arglist)
>  {

I don't think we can simply remove a function that was already present
in one or more Emacs releases.  We need to provide a backward
compatibility layer, and definitely also mention this in NEWS.

This is purely internal, and we can change implementation details at will. I've added a NEWS entry, though. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]