All the needed memory has been allocated before the loop so we can use
copy_screen_chars() directly. This avoids the assertion failure in
copy_chars() for width==0 and should be a bit faster too. According
to ISO/IEC 9899:1999 7.21.1p2, memcpy() doesn't copy anything if n==0
(but the pointers must be valid).
(original 'git cherry-pick' arguments: cherry-pick bug968-att394)
<http://www.wikipedia.org/w/wiki.phtml?search=sue%20lawley>
incorrectly redirects to
<http://en.wikipedia.org/w/wiki.phtml?search=sue%2520lawley>
which searches for "sue%20lawley" rather than "sue lawley".
By using en.wikipedia.org directly, we avoid the server bug.
Prompted by an elinks-users post on 2007-07-27.
I asked on #wikimedia-tech, and www.wikipedia.org does always
redirect to en.wikipedia.org; it does not guess any other
language based on headers or IP addresses or such. Also, the
redirection exists only for compatibility, and skipping it
avoids a few roundtrips to the server. So this change is good
even if the server is eventually fixed.
There were conflicts in src/document/css/ because 0.12.GIT switched
to LIST_OF(struct css_selector) and 0.13.GIT switched to struct
css_selector_set. Resolved by using LIST_OF(struct css_selector)
inside struct css_selector_set.
Rename struct key to struct named_key, use more const, change the num
member from int to term_event_key_T, and put a KBD_UNDEF at the end of
the array (even though it won't be read).
Fix warnings:
dom/stack.h:70: Warning: explicit link request to 'pop_dom_node' could not be resolved
dom/stack.h:71: Warning: explicit link request to 'pop_dom_nodes' could not be resolved
dom/stack.h:71: Warning: explicit link request to 'pop_dom_state' could not be resolved
dom/stack.h:115: Warning: explicit link request to 'done_dom_node' could not be resolved
Use @returns instead of \return in src/document/css/parser.c,
and other such things.
This cleans up and changes the calling convention of
load_additional_file(), so that it now grab its own doc_view using
current_frame() and the struct session pointer in the file_to_load
object. By always looking up the current frame, corruption of doc_view
due to rerendering of the upper frame document is avoided.
The fix extends commit 6afdbf608f by
Witold, which moved the getting of doc_view in the other caller of
load_additional_file(). The additional clean up ensures that any future
users of load_additional_file() will not reintroduce a similar bug.
A possible future optimization would be to change load_additional_file()
to take the referrer as an argument.
When skipping "@media print { #foo {bar: baz} pre {white-space: normal} }",
the previous code would look for the first "{" and then the first "}", and
fail to skip the "pre" rule. Seen at support.microsoft.com.
I originally posted this change as part of attachment 383 to bug 722.
The Free Software Foundation has distributed the GNU gettext manual
under at least two different licenses (a brief copyleft and GNU FDL),
but neither of those seems compatible with the GPLv2 of ELinks.
* All arguments must now be given as options.
* Documented.
* chmod +x in Git.
* Do not distribute files whose contents should depend on what the
configure script found: config.h, config.log, config.status,
features.log, Makefile.config, contrib/conv/w3m2links.awk,
contrib/lua/hooks.lua, doc/man/man1/elinks.1.
* Do not distribute other files that configure will rebuild anyway:
src/intl/gettext/ref-add.sed, src/intl/gettext/ref-del.sed.
But do distribute contrib/elinks.spec, because it specifies how
to run configure, and only the @VERSION@ varies in it.
* Do not distribute the empty directory po/.deps.
* Save the commit ID into .git/HEAD in the tar file.
* Compress the *.tar.gz and *.tar.bz2 from the same *.tar file.
* Instead of *.tar.gz.md5 and *.tar.bz2.md5, generate a *.md5 file
that contains md5sums for *.tar, *.tar.gz, and *.tar.bz2.
* Use md5sum --binary for the sake of Windows.
This patch changes normalize_uri() to no replace "//" with "/" in URIs. This
fixed this bug but will also lead to possibility that duplicate entries can
exist in ELinks' cache. ELinks might be able to detect in another way by
hashing the content or something.
[ From attachment 310 of bug 744. --KON ]
