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.
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
This legacy header appears to be unused. Removing its includes
avoids numerous warnings when compiling with musl libc:
/usr/include/sys/signal.h:1:2: warning: #warning redirecting incorrect #include <sys/signal.h> to <signal.h> [-Wcpp]
The long term goal is good looking of the Python docs in ELinks, especially
background colors. Every start tag and every text node would have associated
a natural number. Those numbers would be "drawn" in the document instead
of colors. Finally, the screen driver would change numbers into colors.
This will be done in small steps. The next step is to implement this change
in the screen driver.
The old code failed to write pending spaces before changing the
background color. That seems hard to fix without duplicating code,
and ELinks pads dumped lines to the requested width in these color
modes anyway, so this commit just makes ELinks write all spaces
immediately when colors are being used.
Try the following command before and after this commit:
elinks --no-home --eval "set document.colors.use_document_colors = 2" \
--dump-color-mode 1 --dump test/color.html
In DUMP_FUNCTION_SPECIALIZED, use isscreensafe_ucs (for UTF-8) or
isscreensafe (for unibyte) to detect control characters, and replace
them with spaces. add_document_to_string already did the same.
In DUMP_FUNCTION_SPECIALIZED (used by elinks --dump), detect the
second cell of double-cell (aka fullwidth) characters by comparing to
UCS_NO_CHAR, like add_document_to_string does. Don't use
unicode_to_cell for this any more.
Also, ignore the colors and attributes of the second cell; don't
output any escape sequences for them.
This is especially useful for showing that neither dump_truecolor_utf8
nor dump_truecolor_unibyte modifies its static color[] variable and it
therefore does not matter whether those functions use the same array
or not.
With all the comments and macros needed for this, the source files
don't become much shorter, but anyway I hope they'll be easier to
maintain this way.
This code was included in four variants of dump_to_file().
Move it to a new function dump_references() and make dump_to_file()
then call that. This makes the code size a little smaller.
The time cost will be negligible.
Instead of having four separate function definitions, have just one
sprinkled with #ifdefs, and #include that four times. The purpose
being to make it clearer which parts of these functions are identical
and which ones differ.
As a side effect, this change makes ELinks ignore --dump-color-mode
when dumping in UTF-8. Colourful UTF-8 dumping has not been
implemented and the fallback is now different from before.
Replace almost all uses of enum connection_state with struct
connection_status. This removes the assumption that errno values used
by the system are between 0 and 100000. The GNU Hurd uses values like
ENOENT = 0x40000002 and EMIG_SERVER_DIED = -308.
This commit is derived from my attachments 450 and 467 to bug 1013.
* Recompute the pos variable for each cell, rather than just once per line.
This fixes the bug that only the first cell was being examined.
* Moved the bulk of the code outside the "if (frame && data >= 176 &&
data < 224)" conditional. This fixes the bug that only frame
characters were being added to the string.
* If the cell has UCS_NO_CHAR in it, don't add that to the string.
* Call encode_utf8 even for characters that originated from a frame.
This does not matter yet but will be correct if the function is
later changed to use the Unicode line-drawing characters for frames.
The configure script no longer recognizes "CONFIG_UTF_8=yes" lines
in custom features.conf files. They will have to be changed to
"CONFIG_UTF8=yes". This incompatibility was deemed acceptable
because no released version of ELinks supports CONFIG_UTF_8.
The --enable-utf-8 option was not renamed.
Suggested by Miciah on #elinks.
What was renamed:
add_utf_8 => add_utf8
cp2utf_8 => cp2utf8
encode_utf_8 => encode_utf8
get_translation_table_to_utf_8 => get_translation_table_to_utf8
goto invalid_utf_8_start_byte => goto invalid_utf8_start_byte
goto utf_8 => goto utf8
goto utf_8_select => goto utf8_select
terminal_interlink.utf_8 => terminal_interlink.utf8
utf_8_to_unicode => utf8_to_unicode
What was not renamed:
terminal._template_.utf_8_io option, TERM_OPT_UTF_8_IO
Compatibility with existing elinks.conf files would require an alias.
--enable-utf-8
Because the name of the charset is UTF-8, --enable-utf-8 looks better
than --enable-utf8.
CONFIG_UTF_8
Will be renamed in a later commit.
Unicode/utf_8.cp, table_utf_8, aliases_utf_8
Will be renamed in a later commit.
Restring the spaghetti in dump_to_file to fix a bug that was introduced
in commit 2a6125e3d0 whereby when
document.dump.codepage != "utf-8", the document itself was not output,
only the references list.
