WATT-32 and openssl you must compile yourself.
You must tweak configure options, something like:
--disable-utf-8, etc.
Only checked on dosemu with LFN. Networking lags is a bit.
Weak points:
- alignof
- js problems
Todo:
- make js work with C++ and mozjs-17
- then mozjs-24
- then mozjs-52
- then mozjs-60
- decrease number of warnings
Makefile.config.in ignored the value of
CONFIG_ECMASCRIPT_SMJS_HEARTBEAT chosen by configure and instead used
the value of CONFIG_ECMASCRIPT_SMJS for it too. This broke building
on SpiderMonkey versions where JS_TriggerOperationCallback is not
available.
No NEWS entry because this bug was not in any ELinks release.
Implement new heartbeat code to catch runaway execution of document
ECMAScript code. The old code uses JS_SetBranchCallback which is
deprecated in new versions of SpiderMonkey. The new code uses setitimer(2)
and the JS_SetOperationCallback and JS_TriggerOperationCallback interfaces,
introduced in SpiderMonkey 1.8.1. Compatibility with both the old
JS_SetBranchCallback and the new interfaces is maintained.
Conflicts:
src/session/session.c: Kept the elinks-0.13 version.
Bug 1077 did not occur in elinks-0.13 because
setup_session here calls render_document_frames
directly and that sets ses->doc_view->vs.
The AsciiDoc 7.1.2 configuration files included in the ELinks
source tree apparently aren't compatible with AsciiDoc 8.4.4:
[ASCIIDOC] doc/elinks.1.xml
FAILED: [listdef-bulleted] missing section: [listtags-None]
make[1]: *** [elinks.1.xml] Error 1
Fix this by including asciidoc.py from AsciiDoc 7.1.2 as well.
The build system now doesn't care at all whether the user has
installed some version of AsciiDoc or not.
When the user tells ELinks to search for a regexp, ELinks 0.11.0
passes the regexp to regcomp() and the formatted document to
regexec(), both in the terminal charset. This works OK for unibyte
ASCII-compatible charsets because the regexp metacharacters are all in
the ASCII range. And ELinks 0.11.0 doesn't support multibyte or
ASCII-incompatible (e.g. EBCDIC) charsets in terminals, so it is no
big deal if regexp searches fail in such locales.
ELinks 0.12pre1 attempts to support UTF-8 as the terminal charset if
CONFIG_UTF8 is defined. Then, struct search contains unicode_val_T c
rather than unsigned char c, and get_srch() and add_srch_chr()
together save UTF-32 values there if the terminal charset is UTF-8.
In plain-text searches, is_in_range_plain() compares those values
directly if the search is case sensitive, or folds them to lower case
if the search is case insensitive: with towlower() if the terminal
charset is UTF-8, or with tolower() otherwise. In regexp searches
however, get_search_region_from_search_nodes() still truncates all
values to 8 bits in order to generate the string that
search_for_pattern() then passes to regexec(). In UTF-8 locales,
regexec() expects this string to be in UTF-8 and can't make sense of
the truncated characters. There is also a possible conflict in
regcomp() if the locale is UTF-8 but the terminal charset is not, or
vice versa.
Rejected ways of fixing the charset mismatches:
* When the terminal charset is UTF-8, recode the formatted document
from UTF-32 to UTF-8 for regexp searching. This would work if the
terminal and the locale both use UTF-8, or if both use unibyte
ASCII-compatible charsets, but not if only one of them uses UTF-8.
* Convert both the regexp and the formatted document to the charset of
the locale, as that is what regcomp() and regexec() expect. ELinks
would have to somehow keep track of which bytes in the converted
string correspond to which characters in the document; not entirely
trivial because convert_string() can replace a single unconvertible
character with a string of ASCII characters. If ELinks were
eventually changed to use iconv() for unrecognized charsets, such
tracking would become even harder.
* Temporarily switch to a locale that uses the charset of the
terminal. Unfortunately, it seems there is no portable way to
construct a name for such a locale. It is also possible that no
suitable locale is available; especially on Windows, whose C library
defines MB_LEN_MAX as 2 and thus cannot support UTF-8 locales.
Instead, this commit makes ELinks do the regexp matching with regwcomp
and regwexec from the TRE library. This way, ELinks can losslessly
recode both the pattern and the document to Unicode and rely on the
regexp code in TRE decoding them properly, regardless of locale.
There are some possible problems though:
1. ELinks stores strings as UTF-32 in arrays of unicode_val_T, but TRE
uses wchar_t instead. If wchar_t is UTF-16, as it is on Microsoft
Windows, then TRE will misdecode the strings. It wouldn't be too
hard to make ELinks convert to UTF-16 in this case, but (a) TRE
doesn't currently support UTF-16 either, and it seems possible that
wchar_t-independent UTF-32 interfaces will be added to TRE; and (b)
there seems to be little interest on using ELinks on Windows anyway.
2. The Citrus Project apparently wanted BSD to use a locale-dependent
wchar_t: e.g. UTF-32 in some locales and an ISO 2022 derivative in
others. Regexp searches in ELinks now do not support the latter.
[ Adapted to elinks-0.12 from bug 1060 attachment 506.
Commit message by me. --KON ]
The build ID now includes both last tagged version, commit generation
since last tagged version, as well as the leading characters of the
commit ID and a flag for dirty working tree.
(cherry picked from commit c2a0d3b969)
This change:
- Adds a check for the doxygen program to configure.
- Moves the Doxyfile from src/Doxyfile to doc/Doxyfile.in.
- Generates a doc/Doxyfile from doc/Doxyfile.in inserting
an absolute path to the source directory, so that it
also works when builddir != srcdir.
- Adds `make api` rule for running doxygen; it depends on
api/doxygen file which is never created to force the rule
to always run.
