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.
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.
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.
Revert commit c9ce4260e5,
which made "elinks -remote http://elinks.cz/" fail with an error
"ELinks: Cannot parse option -remote: Remote method not supported"
even though doc/remote.txt says it should open the URL in a new tab.
Added document.cache.interval option. When time elapsed since previous access
to the document is less than interval then the document is taken from
the cache. Otherwise the request with filled "If-Modified-Since" and/or
"If-None-Match" header field is sent. By default interval is set to 10 minutes.
This requires the correct time to be set on your machine.
The configure script no longer recognizes "CONFIG_UTF_8=yes" lines
in custom features.conf files. They will have to be changed to
"CONFIG_UTF8=yes". This incompatibility was deemed acceptable
because no released version of ELinks supports CONFIG_UTF_8.
The --enable-utf-8 option was not renamed.
The message appears when the user has selected e.g. "Main mapping"
rather than an action inside it. Because the main mapping is a keymap,
ELinks must not tell the user to select a keymap.
According to Jonas Fonseca, if init_string(&canonical) fails, then it
anyway sets canonical.source = NULL and makes done_string(&canonical)
safe, even if canonical was previously uninitialized.
Actions can now be bound to e.g. Ctrl-Alt-A. The keybinding code also
supports other combinations of modifiers, like Shift-Ctrl-Up, but the
escape sequence decoder doesn't yet.
Don't let Ctrl-Alt-letter combinations open menus.
This fixes a bug: in the previous version, l_bind_key() modified the
buffer whose address lua_tostring() returned, even though that is not
allowed according to Lua documentation <http://www.lua.org/pil/24.2.2.html>.
The change affects the user interface: previously, if the user typed
"ctrl+cokebottle" in the "Add keybinding" dialog box, ELinks would
change the text in the widget to "Ctrl-cokebottle" before complaining
that the keystroke is invalid. Now, it leaves the widget unchanged.
This commit does not yet add const to parameters of parse_keystroke()
and related functions.
Before really_add_keybinding() is called, check_keystroke() calls
parse_keystroke(), which converts the modifier prefix to canonical
form: for example, "alt+f9" becomes "Alt-f9". This commit makes
really_add_keybinding() normally ignore that string and generate a
brand new one, e.g. "Alt-F9" (note the upper-case F), for its
"Keystroke already used" warning. Likewise, " " turns to "Space".
After this commit, it should be possible to change parse_keystroke()
to never write back into its input string.
If really_add_keybinding() cannot generate the string for some reason
(out of memory?), then it will use whatever parse_keystroke() has left
in the buffer. The alternatives would be to omit the keystroke name
from the warning or to reject the keybinding entirely; it isn't clear
what the best solution is here, but the one I implemented is closest
to the previous behaviour.
