elinks supports SpiderMonkey 78 (from 2020) and not only 1.5 (from
2000). This is not documented yet.
Removed `js-1.5-rc6a+elinks.patch` because the Meson build script expect
SpiderMonkey 78 for which this patch is irrelevant. Also, you can build
elinks with the vanilla SpiderMonkey 78, that is without needing to
apply any patch.
Removed the documentation on building SpiderMonkey 1.5 because this is
not relevant anymore.
Updated the documentation to use `meson build` instead of `autogen.sh`.
I think the autogen.sh doesn't yet support new SpiderMonkey versions.
SpiderMonkey was updated to mozjs24. If you want to build elinks
with ecmascript support, you must compile using g++ with -fpermissive .
There is a lot of warnings.
There are some memleaks in ecmascript code, especially related to JSAutoCompartment.
I don't know yet, where and how to free it.
Debian does not support mozjs24, so I'm going to gradually update SpiderMonkey version.
ui.clipboard_file is filename of the clipboard file. This file can be a named pipe.
See contrib/clipboard/clip.sh how to set up copying to clipboard using socat and xclip.
Just run clip.sh (it will be running in a loop) before starting elinks and
set ui.clipboard_file = "~/.elinks/clipboard.fifo".
In contrib/user.css, point out that document.colors.use_document_colors
must be enabled for colors to work and ELinks must be compiled with
--enable-html-highlighting for HTML highlighting to work.
That was a remnant from the time when mkdist created a .git/HEAD
referring to the commit from which the distribution was made.
Nowadays, it creates git-commit-id instead.
hooks.py file in the ELinks distribution will fail with an ImportError
exception for any user who hasn't also installed contrib/python/lp3.py.
For the benefit of users who may not otherwise need that file, I'd
suggest delaying the import of lp3 until it's actually used so that
the rest of hooks.py will still work without it.
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.
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.
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.
To segregate the historical commits (can't remember why),
I originally placed their pack in an alternate object store,
but later I found that a *.keep file does the job as well.
This gives a considerable speedup in git gc. It takes some
more disk space but OTOH you might then run gc more often
and have fewer loose objects.
real user sys (tested in this order)
1m15.900s 0m59.732s 0m4.336s gc after clone&graft without *.keep
0m23.162s 0m17.549s 0m1.588s gc after clone&graft with *.keep
0m06.932s 0m04.440s 0m0.588s gc after clone&graft&gc with *.keep
0m32.214s 0m24.138s 0m2.284s gc after clone&graft&gc without *.keep
Total size of .git/objects/pack/ was 90592 KiB without *.keep
and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80%
but increased disk space usage by 7.5%.
The fully dashed form git-update-server-info is deprecated
in Git 1.5.4 and will cease to work in Git 1.6.0 (unless
PATH is modified). Use git update-server-info instead.
* 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.
Files in the debian directory aren't being kept up to date.
(For example, debian/control declares a dependency on libgnutls11-dev
even though ELinks now requires at least 1.2, and debian/changelog
does not mention the 0.11.* releases.)
Until the files are up to date again and there is a commitment to keep
them so, they belong in contrib.
