Documentation strings of most options used to contain a "\n" at the
end of each source line. When the option manager displayed these
strings, it treated each "\n" as a hard newline. On 80x24 terminals
however, the option description window has only 60 columes available
for the text (with the default setup.h), and the hard newlines were
further apart, so the option manager wrapped the text a second time,
resulting in rather ugly output where long lones are interleaved with
short ones. This could also cause the text to take up too much
vertical space and not fit in the window.
Replace most of those hard newlines with spaces so that the option
manager (or perhaps BFU) will take care of the wrapping. At the same
time, rewrap the strings in source code so that the source lines are
at most 79 columns wide.
In some options though, there is a list of possible values and their
meanings. In those lists, if the description of one value does not
fit in one line, then continuation lines should be indented. The
option manager and BFU are not currently able to do that. So, keep
the hard newlines in those lists, but rewrap them to 60 columns so
that they are less likely to require further wrapping at runtime.
I am reverting all copiousoutput support because of bug 917.
This reverts commit 6ead4e9c65.
Conflicts:
src/session/download.c: TERM_EXEC_FG and TERM_EXEC_BG had been
added after the original commit.
Currently, when ELinks passes the name of a local file to an external
MIME handler program, it encodes the name as a URI. Programs
typically do not expect this, and they then fail to open the file.
ELinks should instead quote the file name for the shell.
Unfortunately, Debian has lines like this in /etc/mailcap:
audio/mpeg; xmms '%s'; test=test "$DISPLAY" != ""
If ELinks were changed to replace the %s with e.g.
'/home/Kalle/doc/Topfield/How to upgraded the Firmware(English).pdf'
(quotes included), then the quotes would cancel out and the shell
would split the file name into multiple arguments. That could even
provide a way for malicious persons to make ELinks run arbitrary
shell commands.
The examples in RFC 1524 all have %s without any quotes.
Debian has two bug reports about the quoting behaviour:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221717
This patch therefore tries to detect whether the %s has been quoted
already, and remove the quotes if so. That way, the next patch will
be able to safely add its own quotes. This removal of quotes applies
only to mailcap files; MIME handlers defined in elinks.conf should
already be in the format preferred by ELinks.
(The patch was attachment 438 of bug 991, by Witold Filipczyk.
This commit message was written by Kalle Olavi Niemitalo.)
Previously, file extensions added or modified via the menu did not get
saved to elinks.conf when config.saving_style was 3 (the default).
This patch makes the file-extension dialog box call option_changed,
which then sets OPT_TOUCHED, so that the option appears modified in
the option manager and will be saved.
Reported and patch reviewed by Witold Filipczyk.
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.
It will grab at the first fragment of the cache entry and try to detect the
content-type by looking for valid HTML. It is very stupid for now, simply
searching for "<html>", which may be bogus in certain circumstances. And I
am not sure if this is better left out and up to the scripting backends,
e.g. SMJS can now modify the cache entry.
A feable fix for bug 396.
Delete the FREE_LIST flag from mi_no_ext so that free_menu_items doesn't
try to free static memory.
This fixes a crash reproducible by deleting every entry under Setup -> File
extensions, opening said menu, and then closing said menu.
Its return value is now an enum that lets callers know whether an
error occurred. However, this commit changes the callers only
minimally, so they do not yet check the return value.
at least under Linux. I didn't test network part of external handlers.
Files in tmpdir must be delete somehow. Maybe make a list of files
to unlink and delete them while quitting ELinks.
Simplify commit 8d4f44f2f1, in particular
detecting MIME types for files. It is more consistent to do it the way
it was already done by the session/download code.
Instead, write a NUL byte to stderr when getting FSP files and only set
cache->content_type when the header string is non-empty.
Additionally it also moves close(stderr) after the fsp_error() in the
file handling part of do_fsp() so the error message is shown with the
correct type.
This changes the init target to be idempotent: most importantly it will now
never overwrite a Makefile if it exists. Additionally 'make init' will
generate the .vimrc files. Yay, no more stupid 'added fairies' commits! ;)
