On Dec 31, 2006, at 11:30am, Kalle Olavi Niemitalo writes:
>src/scripting/python/hooks.c (script_hook_url) calls hooks as
>goto_url_hook(new-url, current-url) and follow_url_hook(new-url).
>It has a comment saying that the current-url parameter exists
>only for compatibility and that the script can instead use
>elinks.current_url(). However, the current-url parameter was
>added in commit 87e27b9b3e and is
>not in ELinks 0.11.2, so any compatibility problems would only
>hit people who have been using 0.12.GIT snapshots. Can we remove
>the second parameter now before releasing ELinks 0.12pre1?
The decision isn't up to me, but I think this is a good idea. Here's a
patch that would update the documentation and hooks.py, as well as hooks.c.
FYI, if this patch is applied then anyone who's still trying to use a
goto_url_hook that expects a second argument will get a "Browser scripting
error" dialog box that says:
An error occurred while running a Python script:
TypeError: goto_url_hook() takes exactly 2 arguments (1 given)
As commit 7db8abf6e7 does for Lua
and the document info box, change the Python scripting backend's
current_document and current_header APIs to use document->cached
instead of find_in_cached so the currently displayed document
will be used rather than the latest version of the document.
cleanup_python and python_done_keybinding_interface called by it
now reset the PyObject *python_hooks, *keybindings variables back
to NULL when they release the references. Without this change,
dangling pointers left in those variables could cause problems
if the Python scripting module were deinitialized and reinitialized.
It looks like such reinitialization is not currently possible though,
because enhancement request 73 (plugins support) has not yet been
implemented.
Now the currently displayed version of the current document,
rather than the latest version of the current document, will be used
for the document info box and the current_document() Lua function.
The configure script checks whether it is possible to compile a use of
POPpx without an n_a variable; if not, the source code then defines
those variables. This is slower than including Perl's patchlevel.h
and comparing the version numbers to 5.8.8 but I expect this to be
more reliable as well.
Before this patch, init_python would crash trying to set up elinks.home
at the Python side. Now it uses None as the value in that case.
Also, init_python no longer adds "(null)" to $PYTHONPATH.
This change does not fix any bug, but the SMJS builtin classes use
negative tinyids already, so I presume this is the preferred practice.
At least it means the tinyids won't have to be renumbered later if
some of these objects are changed to behave as arrays.
This reverts baf7b0e91d:
Fix segfaults caused by ruby scripting (gentoo bug #121247).
which reverted 5145ae266a:
Change the Python, Ruby, and SEE hooks for pre-format-html to work
properly now that they are given a non-NUL-terminated string.
and also makes the Ruby hooks interface generally use rb_str_new(str, len)
in favor of rb_str_new2(str) to avoid relying on NUL-terminated being
handled correctly by Ruby. Also, it was wrong for the preformat hook which
is not always handed a NUL-terminated string. Finally, the gentoo bug
(http://bugs.gentoo.org/show_bug.cgi?id=121247) is currently reopened which
suggests that the previous fix was not correct.
If ECMAScript code does obj[42], then the getProperty or setProperty
function of the JSClass of obj gets 42 as the property ID and must not
treat that as an internal error.
The getProperty and setProperty functions of a JSClass must not assume
that the obj parameter points to an instance of that class. It might
instead point to another object that merely has an instance of the
class in its prototype chain. Thus, do not assert that JS_InstanceOf
returns true there. Instead, run the check even with CONFIG_FASTMEM,
and just return JS_FALSE if it fails.
Before, when one assigned a value other than a function to
elinks.preformat_html, elinks.goto_url_hook, or elinks.follow_url_hook,
an assertion failure was triggered (and probably worse happened in
non-DEBUG builds). Now just fail silently.
It is similar to lua's execute and let's you run a command line in
'non-blocking' mode. Example:
elinks.keymaps.main["F"] = function () {
elinks.execute("firefox " + elinks.location);
};
Items can be accessed via elinks.globhist["http://www.foo.net/"]. The
resulting object has title, url, and last_visit properties. last_visit
is the seconds since the epoch. See comments in the code for why I don't
provide a nicer interface for last_visit.
Use info_box directly instead of via report_scripting_error by way of
alert_smjs_error, thereby avoiding the addition of extra text saying
that an error has occurred.
This changes the init target to be idempotent: most importantly it will now
never overwrite a Makefile if it exists. Additionally 'make init' will
generate the .vimrc files. Yay, no more stupid 'added fairies' commits! ;)
the same accelerator key to multiple buttons in a dialog box or
to multiple items in a menu. ELinks already has some support for
this but it requires the translator to run ELinks and manually
scan through all menus and dialogs. The attached changes make it
possible to quickly detect and list any conflicts, including ones
that can only occur on operating systems or configurations that
the translator is not currently using.
The changes have no immediate effect on the elinks executable or
the MO files. PO files become larger, however.
The scheme works like this:
- Like before, accelerator keys in translatable strings are
tagged with the tilde (~) character.
- Whenever a C source file defines an accelerator key, it must
assign one or more named "contexts" to it. The translations in
the PO files inherit these contexts. If multiple strings use
the same accelerator (case insensitive) in the same context,
that's a conflict and can be detected automatically.
- The contexts are defined with "gettext_accelerator_context"
comments in source files. These comments delimit regions where
all translatable strings containing tildes are given the same
contexts. There must be one special comment at the top of the
region; it lists the contexts assigned to that region. The
region automatically ends at the end of the function (found
with regexp /^\}/), but it can also be closed explicitly with
another special comment. The comments are formatted like this:
/* [gettext_accelerator_context(foo, bar, baz)]
begins a region that uses the contexts "foo", "bar", and "baz".
The comma is the delimiter; whitespace is optional.
[gettext_accelerator_context()]
ends the region. */
The scripts don't currently check whether this syntax occurs
inside or outside comments.
- The names of contexts consist of C identifiers delimited with
periods. I typically used the name of a function that sets
up a dialog, or the name of an array where the items of a
menu are listed. There is a special feature for static
functions: if the name begins with a period, then the period
will be replaced with the name of the source file and a colon.
- If a menu is programmatically generated from multiple parts,
of which some are never used together, so that it is safe to
use the same accelerators in them, then it is necessary to
define multiple contexts for the same menu. link_menu() in
src/viewer/text/link.c is the most complex example of this.
- During make update-po:
- A Perl script (po/gather-accelerator-contexts.pl) reads
po/elinks.pot, scans the source files listed in it for
"gettext_accelerator_context" comments, and rewrites
po/elinks.pot with "accelerator_context" comments that
indicate the contexts of each msgid: the union of all
contexts of all of its uses in the source files. It also
removes any "gettext_accelerator_context" comments that
xgettext --add-comments has copied to elinks.pot.
- If po/gather-accelerator-contexts.pl does not find any
contexts for some use of an msgid that seems to contain an
accelerator (because it contains a tilde), it warns. If the
tilde refers to e.g. "~/.elinks" and does not actually mark
an accelerator, the warning can be silenced by specifying the
special context "IGNORE", which the script otherwise ignores.
- msgmerge copies the "accelerator_context" comments from
po/elinks.pot to po/*.po. Translators do not edit those
comments.
- During make check-po:
- Another Perl script (po/check-accelerator-contexts.pl) reads
po/*.po and keeps track of which accelerators have been bound
in each context. It warns about any conflicts it finds.
This script does not access the C source files; thus it does
not matter if the line numbers in "#:" lines are out of date.
This implementation is not perfect and I am not proposing to
add it to the main source tree at this time. Specifically:
- It introduces compile-time dependencies on Perl and Locale::PO.
There should be a configure-time or compile-time check so that
the new features are skipped if the prerequisites are missing.
- When the scripts include msgstr strings in warnings, they
should transcode them from the charset of the PO file to the
one specified by the user's locale.
- It is not adequately documented (well, except perhaps here).
- po/check-accelerator-contexts.pl reports the same conflict
multiple times if it occurs in multiple contexts.
- The warning messages should include line numbers, so that users
of Emacs could conveniently edit the conflicting part of the PO
file. This is not feasible with the current version of
Locale::PO.
- Locale::PO does not understand #~ lines and spews warnings
about them. There is an ugly hack to hide these warnings.
- Jonas Fonseca suggested the script could propose accelerators
that are still available. This has not been implemented.
There are three files attached:
- po/gather-accelerator-contexts.pl: Augments elinks.pot with
context information.
- po/check-accelerator-contexts.pl: Checks conflicts.
- accelerator-contexts.diff: Makes po/Makefile run the scripts,
and adds special comments to source files.
Jonas pointed out, .length is read-only, so SpiderMonkey will never
pass the setter CACHE_ENTRY_LENGTH. Anyway, .uri is also read-only and
is not handled in the setter.
Either set CONFIG_SM_SCRIPTING in features.conf or pass to ./configure the
option --disable-sm-scripting. Now scripting is also enabled when needed
and not only if some other scripting backend is enabled.
Remove some remnants of SEE scripting backend.
Introduce smjs_init_keybinding_interface, which creates elinks.keymaps.<map>
for <map> in "main", "edit", and "menu". elinks.keymaps.<map> is a hash
indexed by string representations of keystrokes, and can be used to get the
current action for a key and to set the action either to an internal ELinks
action or to an ECMAScript function.
the Python, Ruby, and SEE hooks for pre-format-html to work properly
now that they are given a non-NUL-terminated string. Thanks to fonseca
for noticing this problem as well as that fixed by the previous commit.
instead of the URI, content, and length of the entry. Change the hooks
to use add_fragment. This should fix the memory leakage when multiple
hooks change the same document, closing bug 703.
It required that the 'context' session was saved in see_ses (similarly to
the lua_ses variable)
Anyway, now you can use
var opt_value = navigator.preference("ui.window_title)
navigator.preference("ui.window_title", false)
navigator.savePreferences()
to get and set optinos + save the changes.
Renames the following things:
ELinks.write() -> alert() or navigator.alert()
ELinks.version -> navigator.appVersion
ELinks.home -> navigator.appHome
The last one is not defined by the client-side javascript interface.
Script errors are now reported either with WDBG() at startup, ERROR()
if SEE decides to abort and using info_box() for everything else, including
script runtime errors.
SEE is David Leonard's Simple Ecmascript Engine. The SEE scripting backend
is very raw and not tested very much. The idea was to see what kind of
creature SEE is (and contradict pasky's aired opinion that no new features
are added anymore ;).
echo 'function goto_url() { return 'localhost'; }' > ~/.elinks/hooks.js
and get local for maximum security ...
FYI: SEE is smaller than Spidermonkey but doesn't have the same kind of
data-driven interface, although it looks like it is possible to build that.
It is a little ugly since I couldn't get $(wildcard) to expand *.o files
so it just checks if there are any *.c files and then link in the lib.o
based on that.
Ditch the building of an archive (.a) in favour of linking all objects in a
directory into a lib.o file. This makes it easy to link in subdirectories
and more importantly keeps the build logic in the local subdirectories.
Note: after updating you will have to rm **/*.a if you do not make clean
before updating.
