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.
Don't cast function pointers; calling functions via pointers of
incorrect types is not guaranteed to work. Instead, define the
functions with the desired types, and make them cast the incoming
parameters. Or define wrapper functions if the return types don't
match.
really_exit_prog wasn't being used outside src/dialogs/menu.c,
and I had to change its parameter type, so it's now static.
Normally, the success msgbox is shown only if the ui.success_msgbox
option is set as 1, and clicking "Do not show anymore" would then
toggle the option to 0, and no more such msgboxes would appear.
However, if there already are two success msgboxes being displayed
(most likely in different terminals), then clicking "Do not show
anymore" in the first of them would reset the option to 0, but doing
the same in the second of them would toggle the option back to 1.
Rename toggle_success_msgbox to disable_success_msgbox, and make it
always reset the option to 0, regardless of the previous value.
In the elinks.conf.5 manual page, the text below the list of modes was
getting included in the last list item. This appears to be a design
error in AsciiDoc. Work around it by moving the text above the list.
The numbering of document.dump.color_mode and terminal._template_.colors
is now the same regardless of compile-time options, unlike in previous
versions. Therefore this version of ELinks may interpret a configuration
file differently from previous versions even if compiled with the same
options. This is unfortunate but the alternatives (keeping the numbering
dependent on configuration options; defining separate options that use
the new numbering; starting the numbers from 10 or so and recognizing the
previous ones only for compatibility) seem even worse.
doc/remote.txt says there must be a nonempty sequence of ASCII
alphabetic characters before the opening parenthesis. Check that
they really are ASCII characters and that the sequence is nonempty.
Thus, elinks -remote '(foo)' now treats the string as an address,
rather than as a command.
Be more strict about the format accepted by the ELinks specific extension
to the -remote URL syntax. That is, commands must begin with a nonempty
sequence of ASCII alphabetic characters followed by optional whitespace and
an opening parenthesis. Also, document the syntax.
Fixes bug 830.
The problem is that if you run elinks in xterm with the default white
background, it will be totally unreadable if transparency is turned
on. We should default to usability in all common environments, eyecandy
lovers can do the extra setup for their specific one.
It also makes the description note that elinks still assumes the
background is black.
Revert commit c9ce4260e5,
which made "elinks -remote http://elinks.cz/" fail with an error
"ELinks: Cannot parse option -remote: Remote method not supported"
even though doc/remote.txt says it should open the URL in a new tab.
Added document.cache.interval option. When time elapsed since previous access
to the document is less than interval then the document is taken from
the cache. Otherwise the request with filled "If-Modified-Since" and/or
"If-None-Match" header field is sent. By default interval is set to 10 minutes.
This requires the correct time to be set on your machine.
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.