The previous code just printed time_t directly with "%ld". Now it
instead first casts to time_print_T (currently long) and then formats
with TIME_PRINT_FORMAT (currently "ld"). So the varargs will now
always match with the format string, even if time_t is longer than
long. This still doesn't correctly format time_t values larger than
LONG_MAX, though. But now it is at least easier to find some of the
places that need to be changed to support that.
I located these time_t-to-string conversions by searching for
str_to_time_t, expires, and last_visit. There are still more places
that assume every interesting time_t value fits either in 32 bits or
in a long, e.g. in the cookie editor and in the ECMAScript interface.
Inspired by bug 6.
* Recompute the pos variable for each cell, rather than just once per line.
This fixes the bug that only the first cell was being examined.
* Moved the bulk of the code outside the "if (frame && data >= 176 &&
data < 224)" conditional. This fixes the bug that only frame
characters were being added to the string.
* If the cell has UCS_NO_CHAR in it, don't add that to the string.
* Call encode_utf8 even for characters that originated from a frame.
This does not matter yet but will be correct if the function is
later changed to use the Unicode line-drawing characters for frames.
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.
This ensures that no other string can have the same address. It
probably never was a problem though, because the strings to which it
can be compared either are allocated from the heap or are in
strings[][] which already has unshared storage.
On Dec 31, 2006, at 11:30am, Kalle Olavi Niemitalo writes:
>src/scripting/python/hooks.c (script_hook_url) calls hooks as
>goto_url_hook(new-url, current-url) and follow_url_hook(new-url).
>It has a comment saying that the current-url parameter exists
>only for compatibility and that the script can instead use
>elinks.current_url(). However, the current-url parameter was
>added in commit 87e27b9b3e and is
>not in ELinks 0.11.2, so any compatibility problems would only
>hit people who have been using 0.12.GIT snapshots. Can we remove
>the second parameter now before releasing ELinks 0.12pre1?
The decision isn't up to me, but I think this is a good idea. Here's a
patch that would update the documentation and hooks.py, as well as hooks.c.
FYI, if this patch is applied then anyone who's still trying to use a
goto_url_hook that expects a second argument will get a "Browser scripting
error" dialog box that says:
An error occurred while running a Python script:
TypeError: goto_url_hook() takes exactly 2 arguments (1 given)
As commit 7db8abf6e7 does for Lua
and the document info box, change the Python scripting backend's
current_document and current_header APIs to use document->cached
instead of find_in_cached so the currently displayed document
will be used rather than the latest version of the document.
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.
