CPPFLAGS was dropped[1] back on 2004-04-24. Then a workaround was
introduced by commit 6d7e9bfe5b to fix
compilation on FreeBSD that used CPPFLAGS to store iconv related flags.
The use of CPPFLAGS with respect to the COMPILE "macro" reappeared in
40e257bedd on 2006-08-05.
This commit makes configure.in print CPPFLAGS and LDFLAGS. Before,
CPPFLAGS and CFLAGS was mixed together in the feature summary. It also
restores the use of CPPFLAGS storing iconv related flags but keeps the
use of the SAVE/RESTORE_FLAGS in the iconv macro.
Reported by Daniel E. Macks <dmacks@netspace.org> on 2005-11-22 in a mail
to elinks-users with the ID: <slrnem7tjs.lvk.dmacks@happy.netspace.org>.
[1] http://pasky.or.cz/gitweb.cgi?p=elinks-history.git;a=commit;h=ebad0e71572b41dac5376e148fe4b1b5cb9ccc33
src/protocol/smb/smb.c: Added #error directives so that this
vulnerable code cannot be accidentally compiled in.
features.conf: Disable CONFIG_SMB by default and explain why.
configure.in: If CONFIG_SMB is enabled, disable it and warn the user.
This is for people who have customized features.conf.
The version checking was recently reworked in commit
14d5ff3b17, however use of 'puts' is wrong
because it returns nil and thus always causes the check to exit with code
1.
The issue was brought up by dalias. Acked on IRC by Thomas Adam.
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.
UCS_ORPHAN_CELL is currently defined as U+0020 SPACE, which was
already used before this macro, so the behaviour does not change,
but the code seems clearer now.
I searched for ' ' and 32 and 0x20 and \x20, and replaced with
UCS_ORPHAN_CELL wherever UCS_NO_CHAR was involved. However,
some BFU widgets first draw spaces and then overwrite with text;
those will require a more complex fix if UCS_ORPHAN_CELL is ever
changed to some other character.
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.
When I first read the warning about "NO NATIONAL CHARS SUPPORT!"
I was amazed: XML is based on Unicode, so why would the authors of the
XBEL specification have botched support for those characters? The bug
is actually in the ELinks implementation of XBEL, and it has already
been entered in the ELinks bugzilla. Make the documentation string
refer to that.
Recognize all of 
 
 with any number of leading
zeroes. (Previously only and 
 were supported.) All of
these are case insensitive.
Treat each CR+LF combination ( ) as a single newline.
Fix bug 834 (various gzip-encoded documents were being truncated),
which I introduced with commit e441361f2c.
Thanks to Witek for reporting the bug, Kalle for determining the
problematic commit, and Jonas for letting me know about the bug report(!).
... mainly bittorrent:// and bittorrent://x
The BitTorrent URL is supposed to contain an embedded URL pointing to a
metainfo file. If this is not the case a "custom" error message will be
shown. Also fixes calling of free_list() on an uninitialized list.
Closes bug 729.
A simple "update" of Hugo Haas' patch posted for bug 107. This of course
also affects the (undocumented?) feature of file:// refering to the local
directory in that directories named "localhost" can no longer be displayed
using file://localhost. Nobody should do that anyway.
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.
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.
This is necessary when using a POSIX-compliant stdio implementation, which
will set the FILE error flag when input from the pipe is exhausted, causing
all subsequent reads to fail.
Adjust the size of to_read for the initial read instead of setting the init
flag and using that later to check whether to read a smaller amount than
the value in to_read. This also affects the realloc call on the initial
read, which was allocating more memory than necessary (altho this
discrepency would be corrected with the realloc for the next read).
