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%.
