"M. Levinson" <[EMAIL PROTECTED]> writes: > The patch includes documentation for Python programmers in doc/python.txt, > and the documentation is also available internally from Python code via > Python's introspection API.
Both currently seem to contain the same text. Would it be a good
idea to generate one from the other, to prevent them from diverging?
Should CONFIG_SMALL exclude the documentation strings from the
elinks binary? I suppose users of CONFIG_SMALL are unlikely to
link with Python, though.
> +/* C wrapper that invokes Python callbacks for input_dialog() OK button. */
> +
> +static void
> +invoke_input_ok_callback(void *data, unsigned char *text)
It would be nice if the comment said this is indirectly used for
the Cancel button as well, and that text is NULL in that case.
> +python_bind_key(PyObject *self, PyObject *args, PyObject *kwargs)
[...]
> + if (!PyArg_ParseTupleAndKeywords(args, kwargs, "sO|s:bind_key", kwlist,
> + &keystroke, &callback, &keymap))
> + return NULL;
I've been thinking of changing ELinks to allow Unicode characters
in keystroke name strings. It would then be important to know
the encoding of the string. It looks like the cleanest way would
be to use the "es" format unit and explicitly select the "utf_8"
encoding, then tell this to whatever function parses the string
in ELinks.
> + if (!add_format_to_string(&event_name, "python-func %p", callback)) {
> + PyErr_SetFromErrno(python_elinks_err);
> + done_string(&event_name);
> + goto rollback;
> + }
> + event_id = bind_key_to_event_name(keymap, keystroke, event_name.source,
> + &error_msg);
This will potentially register an unbounded number of events,
and there is no unregister_event(). The Lua and SMJS scripting
modules have the same problem (the others apparently cannot bind
keys), and there is a related TODO in free_keybinding().
Perhaps it is a bad idea in general to use the event registration
system for key bindings. There will be only one hook for each
such event, anyway. Instead, the event member of struct
keybinding could be replaced with a pointer to a new structure:
struct scripting_function {
/* Could move the function pointers to a separate vtable. */
/* Called by free_keybinding(). Free this struct
* scripting_function and any language-specific data to which
* it may point. If the scripting language module uses the
* same struct scripting_function for multiple key bindings,
* then *release might just decrement a reference count. */
void (*release)(struct scripting_function *);
/* Called by send_kbd_event(). Execute the scripting
* function. */
void (*call)(struct scripting_function *, struct session *);
};
struct python_scripting_function {
struct scripting_function base;
PyObject *callback;
};
You wouldn't then need the keybindings dictionary, I think.
Perhaps the same structure could be used for script-generated
menus, too; or perhaps there are better solutions.
> diff --git a/src/scripting/python/load.h b/src/scripting/python/load.h
I'll read the rest later.
> diff --git a/src/scripting/python/hooks.c b/src/scripting/python/hooks.c
> index af9b618..23a07f0 100644
> --- src/scripting/python/hooks.c
> +++ src/scripting/python/hooks.c
The hooks.c and hooks.py patches were inconvenient to apply
because their --- and +++ lines did not have the a/ and b/
prefixes like the other patches did.
pgpzbyLRN8T21.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
