This change assumes that option change hooks allow a NULL session.
The only one that did not was change_hook_css, which I fixed in
commit 4adcae682fd26ac5f2664722150987d355956110.
This change allows screen_driver_change_hook to detect that the
charset has been changed to UTF-8 and set screen_driver.utf8 = 1.
redraw_screen then calls get_screen_driver, which propagates the flag
to terminal.utf8. That in turn avoids an assertion failure in
handle_interlink_event.
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.
Document what happens if goto_url_hook or follow_url_hook returns None or "".
doc/events.txt already explains the corresponding C values.
[ commit message by me --KON ]
* 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.
