Re: Dynamic loading progress

[Stephen Leake]

Ted Zlatanov <address@hidden> writes:

> On Tue, 21 Apr 2015 10:58:06 +0200 Aurélien Aptel <address@hidden> wrote: 
>
> AA> On Tue, Apr 21, 2015 at 1:38 AM, Ted Zlatanov <address@hidden> wrote:
>>> I like it. Can you provide a simple example in the branch of how it
>>> would be used from both sides? I can restart the testing and keep it in
>>> sync with the Emacs repo again.
>
> AA> It's already in there:
>
> AA> 
> https://github.com/aaptel/emacs-dynamic-module/tree/dynamic-modules-2/modules/basic
>
> Right!
>
> As far as the coding style and barriers this enforces, I think it's just
> right.  Thanks to you and Dan Colascione and the others for working on
> it.

+1

> As far as capabilities, the basic module should have a string exchange,
> as you've started to implement in `copy_string_contents'
> and `make_string'.  I think it's impossible to move forward without
> that.

For my parser module, I plan on calling the elisp lexer currently in
ada-mode (which uses the sytax class information, forward-sexp, etc).
That avoids copying the entire buffer text to the module, or dealing
with direct access. I haven't got it working yet, so I'm not entirely
sure that will be fast enough, but the lexer is a small portion of the
full parser.

> I would go simple for now: always make a copy of the string using UTF-8
> encoding in the args, assuming that the majority of C modules can deal
> with it, and we can stop worrying about string sharing and encoding for
> now (we can revisit them later). We should free the copy right after
> calling so the module doesn't have to free it.

I'm not clear who is freeing what here; the module API does need to
document that clearly.

We also need to document the GCPRO issues; for example, given the
following call:

  emacs_value pairs[] =
    { env->make_fixnum (env, 1), ada_grammar_names[341], /* statement-start */
      env->make_fixnum (env, 2), ada_grammar_names[342], /* statement-other */
      env->make_fixnum (env, 4), ada_grammar_names[343]  /* statement-end */
    };

  emacs_value args_2[] = { env->funcall (env, vector, 6, pairs) };

  env->funcall (env, wisi_statement_action, 1, args_2);

where 'wisi_statement_action' is an elisp function that uses 'pairs' to
set text properties, should the module do GCPRO around the funcall, or
does the funcall handle that?

Also, we need to do something about the doc strings for lisp objects
declared in modules. I don't think they need to be available before the
module is loaded; if a particular author wants that, they can define an
elisp wrapper with autoloads.

At a minimum, default doc string should be provided that gives a pointer
to the module source code.

> I think `plugin_is_GPL_compatible' should be a float indicating the GPL
> version.  Maybe even a char[] to express flavors, from a constrained set
> of choices.

+1 for the char[]. The variable could be named 'license_terms', so it
could be used by non-GPL in special circumstances.

-- 
-- Stephe