Previously, html_special_form_control converted
form_control.default_value to the terminal charset, and init_form_state
then copied the value to form_state.value. However, when CONFIG_UTF8
is defined and UTF-8 I/O is enabled, form_state.value is supposed to
be in UTF-8, rather than in the terminal charset.
This mismatch could not be conveniently fixed in
html_special_form_control because that does not know which terminal is
being used and whether UTF-8 I/O is enabled there. Also, constructing
a conversion table from the document charset to form_state.value could
have ruined renderer_context.convert_table, because src/intl/charsets.c
does not support multiple concurrent conversion tables.
So instead, we now keep form_control.default_value in the document
charset, and convert it in the viewer each time it is needed. Because
the result of the conversion is kept in form_state.value between
incremental renderings, this shouldn't even slow things down too much.
I am not implementing the proper charset conversions for the DOM
defaultValue property yet, because the current code doesn't have
them for other string properties either, and bug 805 is already open
for that.
I am going make fc->default_value use the charset of the document, and
recoding the string from the form history to that might lose characters.
This change also affects what ECMAScript sees in the defaultValue property.
<http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-26091157>
says it should represent the HTML "value" attribute, so changing it
based on form history is not appropriate.
This does not yet fix bug 947 for the case where the document is UTF-8
and the terminal is ISO-8859-1. That will require changing charsets.c
too, it seems.
This is the mkdist to which doc/release.txt refers.
The script was originally written by Pasky and then modified by Fonseca.
This version doesn't know the correct directory names and so won't work
without modifications, but it seems better to check it in now than wait.
Files in the debian directory aren't being kept up to date.
(For example, debian/control declares a dependency on libgnutls11-dev
even though ELinks now requires at least 1.2, and debian/changelog
does not mention the 0.11.* releases.)
Until the files are up to date again and there is a commitment to keep
them so, they belong in contrib.
Use admonishment elements, especially WARNING for insecure temporary files.
Don't say anything about enabling system functions.
Linuxgames.com no longer uses <CENTER>.
AppWatch.com was shut down on 2001-08-31.
Use the http: AsciiDoc macro instead of link:http:.
Identify the supported version of Lua. Mention the related bug 742.
"Help | About" nowadays groups scripting backends under "Scripting".
Document proxy_for_hook.
The enable_systems_functions function has been removed.
The setlocale function is nowadays called os.setlocale, and it does
affect the operation of ELinks.
The execute function does not return the exit code.
Document tmpname, edit_bookmark_dialog, xdialog, set_option, get_option.
Document elinks_home.
However, I did not update the example Lua scripts.
