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.
The solution with fork() is more general, but it unnecessarily produces two new
process: one in exe_no_stdin(), one in system(). The solution with FD_CLOEXEC
is simpler as it only requires changing and restoring a flag of stdin, but I
suspect it may not be available in all OSes elinks can be compiled for.
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".
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]
If ELinks was configured --without-x, the build failed at
xprop_to_string:
.../src/osdep/osdep.c:500: error: expected ‘)’ before ‘*’ token
Fix by moving xprop_to_string into the #ifdef HAVE_X11 section.
Reported by Thomas Adam.
If Xutf8TextPropertyToTextList or XmbTextPropertyToTextList returns a
positive number, that means some characters were unconvertible and
have been replaced with XDefaultString(). Use the resulting string
even in that case, as if the function had returned Success.
The previous version ignored the string and didn't even free it.
gnome-terminal 2.30.2 expects UTF-8 in the "OSC Ps ; Pt BEL" sequence
that sets the window title. However, XGetWMName typically returns the
title in "STRING" (Latin-1) or "COMPOUND_TEXT" (escape sequences)
encoding. Recode the title to restore it correctly. This helps
especially in the fi_FI.UTF-8 locale, where gnome-terminal has "Pääte"
as the default title.
Related to bugs 885 and 336.
C99 6.7.4p3 and 6.7.4p6 set some constraints on what can be done in
inline functions and how they can be declared. In particular, any
function declared inline must also be defined in the same translation
unit. To comply with that, remove inline specifiers from function
declarations in header files when the functions are not also defined
in those header files.
Sun Studio 11 on Solaris 9 is stricter than C99 and does not allow
references to static identifiers in extern inline functions. Make the
configure script detect this and define NONSTATIC_INLINE accordingly
in config.h. Then use that in the definitions of all non-static
inline functions.
Document the restrictions and this scheme in doc/hacking.txt.
When ELinks runs in an X11 terminal emulator (e.g. xterm), or in GNU
Screen, it tries to update the title of the window to match the title
of the current document. To do this, ELinks sends an "OSC 1 ; Pt BEL"
sequence to the terminal. Unfortunately, xterm expects the Pt string
to be in the ISO-8859-1 charset, making it impossible to display e.g.
Cyrillic characters. In xterm patch #210 (2006-03-12) however, there
is a menu item and a resource that can make xterm take the Pt string
in UTF-8 instead, allowing characters from all around the world.
The downside is that ELinks apparently cannot ask xterm whether the
setting is on or off; so add a terminal._template_.latin1_title option
to ELinks and let the user edit that instead.
Complete list of changes:
- Add the terminal._template_.latin1_title option. But do not add
that to the terminal options window because it's already rather
crowded there.
- In set_window_title(), take a new codepage argument. Use it to
decode the title into Unicode characters, and remove only actual
control characters. For example, CP437 has graphical characters in
the 0x80...0x9F range, so don't remove those, even though ISO-8859-1
has control characters in the same range. Likewise, don't
misinterpret single bytes of UTF-8 characters as control characters.
- In set_window_title(), do not truncate the title to the width of the
window. The font is likely to be different and proportional anyway.
But do truncate before 1024 bytes, an xterm limit.
- In struct itrm, add a title_codepage member to remember which
charset the master said it was going to use in the terminal window
title. Initialize title_codepage in handle_trm(), update it in
dispatch_special() if the master sends the new request
TERM_FN_TITLE_CODEPAGE, and use it in most set_window_title() calls;
but not in the one that sets $TERM as the title, because that string
was not received from the master and should consist of ASCII
characters only.
- In set_terminal_title(), convert the caller-provided title to
ISO-8859-1 or UTF-8 if appropriate, and report the codepage to the
slave with the new TERM_FN_TITLE_CODEPAGE request. The conversion
can run out of memory, so return a success/error flag, rather than
void. In display_window_title(), check this result and don't update
caches on error.
- Add a NEWS entry for all of this.
src/config/kbdbind.c (parse_keystroke): If the user types "Ctrl-i",
it should mean "Ctrl-I" rather than "Ctrl-İ", because the Ctrl-
combinations are only well known for ASCII characters. This does not
matter in practice though, because src/terminal/kbd.c converts 0x09
to (KBD_MOD_NONE, KBD_TAB) and not to (KBD_MOD_CTRL, 'I').
src/osdep/beos/beos.c (get_system_env): Changing the locale does not
affect the TERM environment variable, I think, so it should not affect
the interpretation either.
On AMD64 apparently, off_t is long but ELinks detected SIZEOF_OFF_T == 8
and defined OFF_T_FORMAT as "lld", which expects long long and so causes
GCC to warn about a mismatching format specifier. Because --enable-debug
adds -Werror to $CFLAGS, this warning breaks the build. When both
SIZEOF_LONG and SIZEOF_LONG_LONG are 8, ELinks cannot know which type
it should use.
To fix this, do not attempt to find a format specifier for off_t itself.
Instead cast all printed off_t values to a new typedef off_print_T that
is large enough, and replace OFF_T_FORMAT with OFF_PRINT_FORMAT which
is suitable for off_print_T altough not necessarily for off_t. ELinks
already had a similar scheme with time_print_T and TIME_PRINT_FORMAT.
Do not clear the IXON flag in termios.c_iflag.
Bug 54 did not actually ask for this flag to be kept,
but the cable I am using doesn't seem to have the handshake
lines connected right, so XON/XOFF is a must at 38400 bps,
at least until ELinks learns to send padding based on terminfo.
Any user who has bound actions to Ctrl+S or Ctrl+Q and finds that
they no longer work should just "stty -ixon" before running ELinks.
We don't have any default bindings for those keys, fortunately.
Actually, don't use the cfmakeraw function at all,
and don't look for it during configure either.
(cherry picked from commit 87f1661314
but moved the NEWS entry into the 0.12 section)
straconcat reads the args with va_arg(ap, const unsigned char *),
and the NULL macro may have the wrong type (e.g. int).
Many places pass string literals of type char * to straconcat. This
is in principle also a violation, but I'm ignoring it for now because
if it becomes a problem with some C implementation, then so will the
use of unsigned char * with printf "%s", which is so widespread in
ELinks that I'm not going to try fixing it now.
This fixes parse_ftp_number to use off_t instead of long to store its
(intermediate) result and return type. It also introduces an OFFT_MAX type
"limit" that is used for validating the size of the parsed number.
A test-case for was added in 37c9bf3f75 to
test-ftp-parser and the patch has been confirmed to fix the test-case by
adamg and me. This closes bug 899, which is a duplicate of debian bug
403139.
Previously, the window sizes computed for xterm were a few pixels off,
and this could result in too few character cells being displayed.
This new version tries to read the window size increment from the
WM_NORMAL_HINTS property set by xterm, and base the computations on
that.
- Include arpa/inet.h to get hton* ntoh* functions.
- Use socklen_t instead of int.
- Try to define PF_INET to AF_INET if it doesn't exist.
Reported-by: Andy Tanenbaum <ast@cs.vu.nl>
... since the latter is for printing int64_T and we don't check for that and
we use PRId64 only for printing values having the off_t types.
Besides off_t has it's own ELinks specific defaults so it should be safer
to use an internal format string. If off_t is 8 bytes use "lld" else use
"ld".
Reported-by: Andy Tanenbaum <ast@cs.vu.nl>
GPM is awful, tho', and this is an ugly hack. Why can't it just report
buttons like everyone else?
Another nice thing is that we don't seem to get the wheel events more
frequently than once in a second or so. Therefore it will work properly
only when you scroll slooooowly. :^)
