[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Oddities with dynamic modules
From: |
Kaushal Modi |
Subject: |
Re: Oddities with dynamic modules |
Date: |
Fri, 12 Oct 2018 10:29:17 -0400 |
On Thu, Oct 11, 2018 at 2:14 PM Eli Zaretskii <address@hidden> wrote:
>
> Having written the documentation of the module API,
Thanks for writing up all that documentation!
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=ce8b4584a3c69e5c4abad8a0a9c3781ce8c0c1f8
I am not in the capacity to comment on most of your questions as I am
using the Modules feature to get around my lack of C knowledge :)
> . Why aren't there API functions to _create_ lists and vectors?
>
> . Using 'funcall' is unnecessarily cumbersome, because the function
> to be called is passed as an 'emacs_value'. Why don't we have a
> variant that just accepts a name of a Lisp-callable function as a C
> string?
+1
I needed to create some sugar syntax in Nim (which compiles to C) to
get around that limitation:
proc MakeList*(env: ptr emacs_env; listArray: openArray[emacs_value]):
emacs_value =
## Return an Emacs-Lisp ``list``.
Funcall(env, "list", listArray)
proc MakeCons*(env: ptr emacs_env; consCar, consCdr: emacs_value): emacs_value =
## Return an Emacs-Lisp ``cons``.
Funcall(env, "cons", [consCar, consCdr])
It would be nice to have API for list (and cons).
> . Why does 'intern' only handle pure ASCII symbol names? It's not
> like supporting non-ASCII names is hard.
>
> . I could understand why equality predicates are not provided in the
> API, but I don't understand why we do provide 'eq' there. Is it
> that much more important than the other predicates?
I had the same question too. I find equal more useful than eq.