* All arguments must now be given as options.
* Documented.
* chmod +x in Git.
* Do not distribute files whose contents should depend on what the
configure script found: config.h, config.log, config.status,
features.log, Makefile.config, contrib/conv/w3m2links.awk,
contrib/lua/hooks.lua, doc/man/man1/elinks.1.
* Do not distribute other files that configure will rebuild anyway:
src/intl/gettext/ref-add.sed, src/intl/gettext/ref-del.sed.
But do distribute contrib/elinks.spec, because it specifies how
to run configure, and only the @VERSION@ varies in it.
* Do not distribute the empty directory po/.deps.
* Save the commit ID into .git/HEAD in the tar file.
* Compress the *.tar.gz and *.tar.bz2 from the same *.tar file.
* Instead of *.tar.gz.md5 and *.tar.bz2.md5, generate a *.md5 file
that contains md5sums for *.tar, *.tar.gz, and *.tar.bz2.
* Use md5sum --binary for the sake of Windows.
The history converted from CVS is not in repo.or.cz though, so keep
referring to pasky.or.cz for that. (We don't seem to use
"gitweb.elinks.cz", which is a DNS alias for pasky.or.cz.)
<paakku> Do you think we should maybe point people to gitweb at
repo.or.cz rather than pasky.or.cz?
<pasky> absolutely
<pasky> actually I thought we already are pointing people at
repo.or.cz
<pasky> at least there was some movement to do that already, I believe
:)
I don't think there is any point in keeping this file when users can
easily run elinks -no-home -config-dump to get an equivalent one.
The result won't include options for features that were disabled at
configure time, but the users won't need those options either.
Furthermore, if this file is installed as /etc/elinks/elinks.conf like
contrib/debian/rules does, and people then modify it, they cannot
easily upgrade to changed defaults in later ELinks versions; these
changes may even be security-related, like ecmascript.enable in the
upcoming ELinks 0.12.0. It is better if /etc/elinks/elinks.conf
contains only the settings that the sysadmin explicitly wants to
change from the defaults, and all the rest comes from the elinks
binary.
This is the mkdist to which doc/release.txt refers.
The script was originally written by Pasky and then modified by Fonseca.
This version doesn't know the correct directory names and so won't work
without modifications, but it seems better to check it in now than wait.
Document what happens if goto_url_hook or follow_url_hook returns None or "".
doc/events.txt already explains the corresponding C values.
[ commit message by me --KON ]
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)
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.
