JS_CallFunction does not support closures in SpiderMonkey versions
earlier than 1.8. Test case:
elinks.keymaps.main["\""] = function() {
elinks.keymaps.main["e"] = function() {
elinks.alert("hello!");
};
}
JS_CallFunction does not support closures in SpiderMonkey versions
earlier than 1.8. Test case:
function set_suffix(suffix) {
elinks.preformat_html = function(cached, vs) {
cached.content += suffix;
}
}
set_suffix("hello");
JS_CallFunction does not support closures in SpiderMonkey versions
earlier than 1.8. Test case:
elinks.keymaps.main["!"] = function() {
elinks.load_uri("http://www.eldar.org/cgi-bin/fortune.pl?text_format=yes",
function (cached) { elinks.alert(cached.content); });
}
Conflicts:
NEWS
configure.in
The following files also conflicted, but they had not been manually
edited in the elinks-0.12 branch after the previous merge, so I just
kept the 0.13.GIT versions:
doc/man/man1/elinks.1.in
doc/man/man5/elinks.conf.5
doc/man/man5/elinkskeys.5
po/fr.po
po/pl.po
elinks.keymaps.main["/"] = null;
used to crash ELinks with a segfault in JS_ObjectIsFunction.
Fix that by recognizing JSVAL_NULL explicitly and treating it as "none".
Likewise, if keymap_get_property would return "none" to ECMAScript,
return JSVAL_NULL instead.
In uri.post, each file name begins and ends with FILE_CHAR.
Previously, file names were not encoded, and names containing
FILE_CHAR could not be used. Because FILE_CHAR is a control
character, the user cannot directly type it in a file input field,
so ELinks asserted that the field did not contain FILE_CHAR.
However, it is possible to get FILE_CHAR in a file input field
with file name completion (ACT_EDIT_AUTO_COMPLETE), causing the
assertion to fail. Now, ELinks encodes FILE_CHAR as "%02", so it
is no longer ambiguous and the assertion is not needed.
Also document elinks.vs and elinks.action.
<kahmalo> Miciah: IMO most of contrib/smjs/README should be moved into
the ELinks manual. Specifically the parts that do not depend on
contrib/smjs/hooks.js. However manual.txt contains a notice:
"Hold blameless the authors. Any lawful use is allowed." Will
you allow that also for what is now in contrib/smjs/README?
<Miciah> Absolutely.
<Miciah> In fact, I would allow some lawless uses.
<Miciah> It seems a little silly to say that lawful uses are allowed.
This reverts commit c33d195ff4.
ELinks no longer needs to collect garbage in this situation
because it can now free cache entries even if the corresponding
SMJS objects remain.
The SpiderMonkey scripting module handles the "pre-format-html" event
by constructing a JSObject for the struct cache_entry and then calling
elinks.preformat_html(cache_entry, view_state) if such a function
exists. The problem with this was that each such JSObject kept the
struct cache_entry locked until SpiderMonkey garbage-collected the
JSObject, even if the user had not defined an elinks.preformat_html
function and the JSObject was thus never needed at all. To work
around that, the SpiderMonkey scripting module ran a garbage
collection whenever the user told ELinks to flush caches.
Remove the SpiderMonkey scripting module's use of object_lock and
object_unlock on struct cache_entry, and instead make the pointers
weak so that ELinks can free the cache_entry whenever it wants even if
a JSObject is pointing to it. Each cache_entry now has a pointer back
to the JSObject; done_cache_entry calls smjs_detach_cache_entry_object,
which follows the pointer and detaches the cache_entry and the JSObject
from each other.
This commit does not yet remove the workaround mentioned above.
It is not necessary: when a rule has multiple commands in it, GNU Make
(which ELinks requires anyway) runs them one at a time, regardless of
the -j option, and skips the remaining commands when one of them
fails, regardless of the -k option. These options take effect at the
level of targets rather than individual commands.
http://elinks.cz/community.html says bugs should be reported
to elinks-users but patches should be sent to elinks-dev.
I guess elinks-users is more appropriate here.
This is so that contrib/mkdist need not delete that explicitly
(although it still does, in order to do the right thing with
a few older versions too).
The file could apparently be removed altogether (see recent
emails on elinks-dev) but a small change like this is less
likely to cause any surprises.
Because http://elinks.cz/release.html is made from this file,
I think we'll have to list both 0.11.4.GIT and 0.12pre1.GIT
even though it's a bit difficult to explain which fixes are
in which releases.
gcc-4.3 -O2 was complaining that http_got_header may use uninitialized
version.major and version.minor. That indeed happened with HTTP/0.9
servers, and the PRE_HTTP_1_1(version) check then had an undefined
result, so http->close could remain 0 even though it should have
become 1; fortunately, it was then set to 1 anyway, because there was
no Content-Length header. The undefined version was also saved in
http->recv_version, but it appears nothing ever reads that. So in the
end, the bug did not cause any symptoms at runtime, but the warning
broke the build on gcc-4.3 if ELinks was configured with --enable-debug.
The following is in the HTML 4 standard
(<http://www.w3.org/TR/html401/interact/forms.html#push-button>):
push buttons: Push buttons have no default behavior. Each push
button may have client-side scripts associated with the element's
event attributes. When an event occurs (e.g., the user presses the
button, releases it, etc.), the associated script is triggered.
Currently, a button such created by such HTML as "<input type="button"
value="foo" />" submits the form by default in ELinks. According to
the above, it shouldn't.
In particular:
- mkdist takes options and need not be run at elinks.cz
- git push just the single tag, rather than all --tags
- explicitly avoid multipart/signed
- add the release date from the elinks-users archive to NEWS
- update download.txt, release.html, and bugzilla/milestones/elinks.html
md5sum -c exits with code 1 if some of the files listed in the md5
file are missing, so each md5 file should list only those files that
the user is supposed to download together. This is also how
elinks-web/download.html has been set up.
.git/HEAD in elinks-0.12pre1.tar.gz broke git-import-orig in Debian's
git-buildpackage 0.4.33:
$ git init
Initialized empty Git repository in .git/
$ git-import-orig ~/src/elinks-seek/elinks-0.12pre1.tar.gz
Upstream version is 0.12pre1
Initial import of '/home/Kalle/src/elinks-seek/elinks-0.12pre1.tar.gz' ...
fatal: bad object HEAD
Traceback (most recent call last):
File "/usr/bin/git-import-orig", line 243, in <module>
sys.exit(main(sys.argv))
File "/usr/bin/git-import-orig", line 201, in main
import_upstream_tree(repo, orig_dir, version, options.filters, verbose=not is_empty)
File "/usr/bin/git-import-orig", line 65, in import_upstream_tree
if replace_source_tree(repo, src_dir, filters, verbose=True):
File "/var/lib/python-support/python2.5/gbp/git_utils.py", line 145, in replace_source_tree
return not repo.is_clean()[0]
File "/var/lib/python-support/python2.5/gbp/git_utils.py", line 78, in is_clean
if out[0].startswith('#') and out[1].strip().startswith(clean_msg):
IndexError: list index out of range
So let's try with a "git-commit-id" file outside of .git/ instead.
I also considered ".git-commit-id" but that could give the impression
that Git itself reads the file for some purpose.
Git does not appear to have anything like cg clone -s, which makes the
clone in the current directory rather than in a new directory. It
seems possible to work around that with:
git clone --bare http://elinks.cz/elinks.git .git
git --git-dir=.git config core.bare false
git reset --hard
git clean -f
git checkout elinks-0.12
but that's already so complex that I think it'll be easier to just
remove the whole directory and clone to a new one.
The whole concept of first downloading a snapshot and then updating
that from version control comes from the time when ELinks was in CVS.
It made sense then because CVS could download deltas based on the data
in the CVS subdirectories contained in the snapshots. However, Git
wants to get the whole history and does not benefit from having the
files of a single commit available in advance.
The documentation has version numbers in a few places and it's easier
to get those right this way than by building it elsewhere before
running mkdist. This change slows down mkdist but ccache can mitigate
some of that and snapshots use prebuilt documentation anyway.
