This check used to be in src/elinks.h. Move it to configure.in so
that (1) the result can be logged and (2) ELinks won't even link with
TRE if wchar_t prevents its use.
Also, rename HAVE_TRE_REGEX_H to CONFIG_TRE, to reflect that it is not
always defined if the header exists.
Check the return value of get_opt_rec on "document.browse.search.regex"
before dereferencing it. The option is not there if regular expression
support is disabled at build time.
This commit fixes a bug introduced in commit
b2d51c75ff0d6c52a4f6a2761801beb641cba3a2.
Check the return value of get_opt_rec on "document.browse.search.regex"
before dereferencing it. The option is not there if regular expression
support is disabled at build time.
This commit fixes a bug introduced in commit
b2d51c75ff0d6c52a4f6a2761801beb641cba3a2.
When the user tells ELinks to search for a regexp, ELinks 0.11.0
passes the regexp to regcomp() and the formatted document to
regexec(), both in the terminal charset. This works OK for unibyte
ASCII-compatible charsets because the regexp metacharacters are all in
the ASCII range. And ELinks 0.11.0 doesn't support multibyte or
ASCII-incompatible (e.g. EBCDIC) charsets in terminals, so it is no
big deal if regexp searches fail in such locales.
ELinks 0.12pre1 attempts to support UTF-8 as the terminal charset if
CONFIG_UTF8 is defined. Then, struct search contains unicode_val_T c
rather than unsigned char c, and get_srch() and add_srch_chr()
together save UTF-32 values there if the terminal charset is UTF-8.
In plain-text searches, is_in_range_plain() compares those values
directly if the search is case sensitive, or folds them to lower case
if the search is case insensitive: with towlower() if the terminal
charset is UTF-8, or with tolower() otherwise. In regexp searches
however, get_search_region_from_search_nodes() still truncates all
values to 8 bits in order to generate the string that
search_for_pattern() then passes to regexec(). In UTF-8 locales,
regexec() expects this string to be in UTF-8 and can't make sense of
the truncated characters. There is also a possible conflict in
regcomp() if the locale is UTF-8 but the terminal charset is not, or
vice versa.
Rejected ways of fixing the charset mismatches:
* When the terminal charset is UTF-8, recode the formatted document
from UTF-32 to UTF-8 for regexp searching. This would work if the
terminal and the locale both use UTF-8, or if both use unibyte
ASCII-compatible charsets, but not if only one of them uses UTF-8.
* Convert both the regexp and the formatted document to the charset of
the locale, as that is what regcomp() and regexec() expect. ELinks
would have to somehow keep track of which bytes in the converted
string correspond to which characters in the document; not entirely
trivial because convert_string() can replace a single unconvertible
character with a string of ASCII characters. If ELinks were
eventually changed to use iconv() for unrecognized charsets, such
tracking would become even harder.
* Temporarily switch to a locale that uses the charset of the
terminal. Unfortunately, it seems there is no portable way to
construct a name for such a locale. It is also possible that no
suitable locale is available; especially on Windows, whose C library
defines MB_LEN_MAX as 2 and thus cannot support UTF-8 locales.
Instead, this commit makes ELinks do the regexp matching with regwcomp
and regwexec from the TRE library. This way, ELinks can losslessly
recode both the pattern and the document to Unicode and rely on the
regexp code in TRE decoding them properly, regardless of locale.
There are some possible problems though:
1. ELinks stores strings as UTF-32 in arrays of unicode_val_T, but TRE
uses wchar_t instead. If wchar_t is UTF-16, as it is on Microsoft
Windows, then TRE will misdecode the strings. It wouldn't be too
hard to make ELinks convert to UTF-16 in this case, but (a) TRE
doesn't currently support UTF-16 either, and it seems possible that
wchar_t-independent UTF-32 interfaces will be added to TRE; and (b)
there seems to be little interest on using ELinks on Windows anyway.
2. The Citrus Project apparently wanted BSD to use a locale-dependent
wchar_t: e.g. UTF-32 in some locales and an ISO 2022 derivative in
others. Regexp searches in ELinks now do not support the latter.
[ Adapted to elinks-0.12 from bug 1060 attachment 506.
Commit message by me. --KON ]
This simplifies the callers a little and may help implement
simultaneous support for different charsets on different terminals
of the same type (bug 1064).
Before this patch, if you first moved the cursor to link X with
move-cursor-up and similar actions, and then clicked link Y with the
mouse, ELinks would activate link X, i.e. not the one you clicked.
This happened because the NAVIGATE_CURSOR_ROUTING mode was left
enabled and made ELinks ignore the doc_view->vs->current_link
member that ELinks had updated according to the click.
Make ELinks return the session to NAVIGATE_LINKWISE mode, so that
the update takes effect.
Reported by Paul B. Mahol.
(cherry picked from commit 4086418069)
In get_entity_string and point_intersect, do not initialise arrays with
static storage duration to zero; the C standard states that such objects
are automatically initialised to zero.
This patch fixes an issue whereby a newline character appearing within
a hidden input field is incorrectly reinterpreted as a space character.
The patch handles almost all cases, and includes a test case.
15/18 tests pass, but the remainder currently fail due to the fact
that ELinks does not currently support textarea scripting.
cache_entry.id => cache_entry.cache_id
document.id => document.cache_id
ecmascript_interpreter.onload_snippets_owner => .onload_snippets_cache_id
This is a combination of:
commit 232c07aa7f
bug 1009: id variables renamed, added document_id to the document.
commit 6007043458bf8f14abfc18b9db60785bdc0279f6
Revert addition of document.document_id
Replace almost all uses of enum connection_state with struct
connection_status. This removes the assumption that errno values used
by the system are between 0 and 100000. The GNU Hurd uses values like
ENOENT = 0x40000002 and EMIG_SERVER_DIED = -308.
This commit is derived from my attachments 450 and 467 to bug 1013.
Check in refresh_view() whether the tab is still current; if not, skip
the draw_doc() and draw_frames() calls because draw_current_link()
called within them asserts that the tab is current. However, do
always call print_screen_status(), because that handles non-current
tabs correctly too.
I think it was not yet possible to trigger the assertion failure with
setTimeout, because input.value modifications by ECMAScript do not
trigger a redraw (bug 1035).
Anything that frees struct form_view must now call the new function
ecmascript_detach_form_view. This function should then clear out any
dangling pointers, but that has not yet been implemented.
Anything that frees or reallocates struct form_state must now call the
new functions ecmascript_detach_form_state or ecmascript_moved_form_state.
These functions should then clear out any dangling pointers, but that has
not yet been implemented.
Commit 0b99fa70ca "Bug 620: Reset form
fields to default values on reload" made render_document() decrement
vs->form_info_len to 0 while vs->form_info remained non-NULL.
copy_vs() then copied the whole structure with copy_struct and did not
change form_info because form_info_len was 0. Both view_state
structures had form_info pointing to the same memory block, causing a
segfault when destroy_vs() tried to free that block a second time.
Reported by أحمد المحمودي.
This change avoids the following error:
gcc -DHAVE_CONFIG_H -I../../.. -I/home/Kalle/src/elinks-0.11/src -I/home/Kalle/prefix/include -I/usr/include/smjs -I/usr/include -I/usr/include/lua50 -I/usr/include -I/usr/include -O0 -ggdb -Wall -Wall -Werror -fno-strict-aliasing -Wno-pointer-sign -Wno-address -fno-strict-overflow -o search.o -c /home/Kalle/src/elinks-0.11/src/viewer/text/search.c
cc1: warnings being treated as errors
/home/Kalle/src/elinks-0.11/src/viewer/text/search.c:257: warning: 'get_search_region_from_search_nodes' defined but not used
make[3]: *** [search.o] Error 1
make[3]: Leaving directory `/home/Kalle/build/i686-pc-linux-gnu/elinks-0.11/src/viewer/text'
get_search_region_from_search_nodes is called only from
search_for_pattern, which already was inside #ifdef HAVE_REGEX_H.
(cherry picked from commit 2aec302d47)
Conflicts:
NEWS
configure.in
The following files also conflicted, but they had not been manually
edited in the elinks-0.12 branch after the previous merge, so I just
kept the 0.13.GIT versions:
doc/man/man1/elinks.1.in
doc/man/man5/elinks.conf.5
doc/man/man5/elinkskeys.5
po/fr.po
po/pl.po
In uri.post, each file name begins and ends with FILE_CHAR.
Previously, file names were not encoded, and names containing
FILE_CHAR could not be used. Because FILE_CHAR is a control
character, the user cannot directly type it in a file input field,
so ELinks asserted that the field did not contain FILE_CHAR.
However, it is possible to get FILE_CHAR in a file input field
with file name completion (ACT_EDIT_AUTO_COMPLETE), causing the
assertion to fail. Now, ELinks encodes FILE_CHAR as "%02", so it
is no longer ambiguous and the assertion is not needed.
The following is in the HTML 4 standard
(<http://www.w3.org/TR/html401/interact/forms.html#push-button>):
push buttons: Push buttons have no default behavior. Each push
button may have client-side scripts associated with the element's
event attributes. When an event occurs (e.g., the user presses the
button, releases it, etc.), the associated script is triggered.
Currently, a button such created by such HTML as "<input type="button"
value="foo" />" submits the form by default in ELinks. According to
the above, it shouldn't.
If ELinks is being linked with SSL library, use its random number
generator.
Otherwise, try /dev/urandom and /dev/prandom. If they do not work,
fall back to rand(), calling srand() only once. This fallback is
mostly interesting for the Hurd and Microsoft Windows.
BitTorrent piece selection and dom/test/html-mangle.c still use rand()
(but not srand()) directly. Those would not benefit from being
unpredictable, I think.
cached->id => cached->cache_id
document->id => document->cache_id
onload_snippets_owner => onload_snippets_document_id
Added the distinct document->document_id.
Always reset ecmascript when a document changes for example a next chunk
of it is loaded.
In the previous version, the first event that had KBD_MOD_PASTE
entered insert mode and was consumed for that; ELinks then inserted
the characters from the remaining events. Now, to make ELinks insert
the first character too, I'm changing things so that KBD_MOD_PASTE
does not cause insert mode to be entered; instead, ELinks inserts
those characters regardless of whether insert mode is on.
in move-link-left-line and others, so move-link-left-line ans others
do not use the keyboard prefix.
(cherry picked from commit 8b281e1404)
(cherry picked from commit 4f2a9eadfc)
Go to the page with a few lines. Follow a link to a page with more lines.
Move cursor down, do not stay on a link.
Go back and do move-link-prev-line. This caused a segmentation fault.
(cherry picked from commit 888ba87516)
(cherry picked from commit 1cbd02c141)
Change mode to NAVIGATE_LINKWISE to preserve the link position when
going back.
(cherry picked from commit 14b37d0362)
(cherry picked from commit a594b2a002)
move-link-down-line moves the cursor down to the line with a link.
move-link-up-line moves the cursor up to the line with a link.
move-link-prev-line moves to the previous link horizontally.
move-link-next-line moves to the next link horizontally.
(cherry picked from commit 8259a56e99)
(cherry picked from commit 2eb3532416)
Go to the page with a few lines. Follow a link to a page with more lines.
Move cursor down, do not stay on a link.
Go back and do move-link-prev-line. This caused a segmentation fault.
(cherry picked from commit 888ba87516)
move-link-down-line moves the cursor down to the line with a link.
move-link-up-line moves the cursor up to the line with a link.
move-link-prev-line moves to the previous link horizontally.
move-link-next-line moves to the next link horizontally.
(cherry picked from commit 8259a56e99)
start_document_refreshes() performs the NULL-pointer checks that
previously all callers to start_document_refresh() must perform
and then calls start_document_refresh().
start_document_refreshes performs the NULL-pointer checks that previously all callers to start_document_refresh must perform and then calls start_document_refresh.
Added EVENT_TEXTAREA used to notify the master terminal
about end of execution of an external program on a slave terminal.
The format of data sent to the master terminal by exec_on_slave_terminal
has changed. Now after 0, fg the value of term is sent.
Therfore this release of ELinks is incompatible with previous releases.
Patch by Witold Filipczyk, taken from his witekfl branch.
Conflicts:
src/viewer/text/textarea.c
Pass the session with some get_opt_* calls. These are the low-hanging fruit. Some places will be difficult because we don't have the session or for other reasons.
Update a comment in encode_multipart, which refers to html_form_control, which has since been renamed to html_special_form_control.
The comment was added with this commit:
commit b4dee890a61a6c8a27a8e4cd1dc3b3b93f1cdb08
Author: Petr Baudis <pasky@ucw.cz>
Date: Fri May 10 13:26:55 2002 +0000
Don't decode and back encode hidden form items (by mikulas, from 0.97).
The function was renamed with this commit:
commit c9d72739c715b3b0c7c6fec582780c1e8f444fc4
Author: Petr Baudis <pasky@ucw.cz>
Date: Sat Dec 18 02:22:28 2004 +0000
html_(tag|form*) -> html_special_\1, to naming prevent conflicts with HTML element handlers. As suggested by Jonas.
I don't remember why I cleared "returns", but it doesn't work
with www.hypermedia.pl/altkom/ and probably with many more sites.
[ From commit e887efc611 on the witekfl
branch. --KON ]
Use it for the actual I/O only. Previously, defining CONFIG_UTF8 and
enabling UTF-8 used to force many strings to the UTF-8 charset
regardless of the terminal charset option. Now, those strings always
follow the terminal charset. This fixes bug 914 which was caused
because _() returned strings in the terminal charset and functions
then assumed they were in UTF-8. This reduction in the effects of
UTF-8 I/O may also simplify future testing.
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.
straconcat reads the args with va_arg(ap, const unsigned char *),
and the NULL macro may have the wrong type (e.g. int).
Many places pass string literals of type char * to straconcat. This
is in principle also a violation, but I'm ignoring it for now because
if it becomes a problem with some C implementation, then so will the
use of unsigned char * with printf "%s", which is so widespread in
ELinks that I'm not going to try fixing it now.
In goto_mark, copy the current_link of the old view state to the
old_current_link of the new view state so that clear_link will properly
clear the highlight for that link.
This fixes a bug introduced with the removal of link_bg in commit
c91c763d49.
* 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.
This allows code to use document->cached instead of
find_in_cache(document->uri), thereby increasing the likelihood
of getting the correct cache entry.
This should fix Bug 756 - "assertion (cached)->object.refcount >= 0 failed"
after HTTP proxy was changed.
Patches for this were written by me and then later by Jonas.
This commit combines our independent implementations.
As draw_textarea_utf8 loops over each character of the textarea content, it
checks whether the character is on the screen; draws it if so; increments
the screen co-ordinate; and updates the position in the textarea text.
The last step was being skipped when the character was not on the line,
so a line would be drawn from the beginning, even if the left edge of the
textarea is off the screen.
Closes: Bug 835 - Text in textarea is unaffected by horizontal scrolling of
document in UTF-8 mode
If utf8_char2cells isn't told where the string that contains
the given UTF-8 character ends, it computes that itself. Two users
of utf8_char2cells, format_textutf8 and split_line, were calling
utf8_char2cells in a loop without providing the end of the string,
resulting in numerous calls by utf8_char2cells to strlen.
With this patch, format_textutf8 and split_line each find the end
of the string once and provide it to utf8_char2cells.
This particularly improves performance with textareas, since
format_textutf8 is called multiple times each time the user interacts
with the textarea and when it must be redrawn.
Closes: Bug 823 - Big textarea is too slow with CONFIG_UTF8
UCS_ORPHAN_CELL is currently defined as U+0020 SPACE, which was
already used before this macro, so the behaviour does not change,
but the code seems clearer now.
I searched for ' ' and 32 and 0x20 and \x20, and replaced with
UCS_ORPHAN_CELL wherever UCS_NO_CHAR was involved. However,
some BFU widgets first draw spaces and then overwrite with text;
those will require a more complex fix if UCS_ORPHAN_CELL is ever
changed to some other character.
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.
Suggested by Miciah on #elinks.
What was renamed:
add_utf_8 => add_utf8
cp2utf_8 => cp2utf8
encode_utf_8 => encode_utf8
get_translation_table_to_utf_8 => get_translation_table_to_utf8
goto invalid_utf_8_start_byte => goto invalid_utf8_start_byte
goto utf_8 => goto utf8
goto utf_8_select => goto utf8_select
terminal_interlink.utf_8 => terminal_interlink.utf8
utf_8_to_unicode => utf8_to_unicode
What was not renamed:
terminal._template_.utf_8_io option, TERM_OPT_UTF_8_IO
Compatibility with existing elinks.conf files would require an alias.
--enable-utf-8
Because the name of the charset is UTF-8, --enable-utf-8 looks better
than --enable-utf8.
CONFIG_UTF_8
Will be renamed in a later commit.
Unicode/utf_8.cp, table_utf_8, aliases_utf_8
Will be renamed in a later commit.
form_state.state_cell is no longer used for FC_TEXT, FC_PASSWORD, nor FC_FILE.
Instead, get_link_cursor_offset() computes the cell with utf8_ptr2chars
(a new function) or utf8_ptr2cells. This shouldn't slow down ELinks too
much, as it's done only for the selected link and only once per redraw.
The left side of a scrolled input field is always aligned at a
character boundary. The right side might not be.
The new comments describe how the members were apparently intended to
be used. However, the implementation does not actually work when
CONFIG_UTF_8 is defined, and the current semantics do not even allow
an efficient implementation of long (mostly scrolled out) strings.
Restring the spaghetti in dump_to_file to fix a bug that was introduced
in commit 2a6125e3d0 whereby when
document.dump.codepage != "utf-8", the document itself was not output,
only the references list.
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.
The cast is not necessary since we already check the bounds, but by using a
cast here, it hopefully makes it more obvious what the long comment above
is pointing out: namely that we put the value of a signed integer into an
unsigned char.
This requires compiling cp2u() in even without CONFIG_UTF_8.
I also added an is_kbd_character macro to make try_document_key
more resilient to changes in the definition of term_event_key_T.
The previous version used only the low 8 bits of the key code.
This one arranges for the whole key to be rejected if it's not ASCII.
Perhaps the modifiers should be checked too, but I'm not changing that now.
Form fields and BFU text-input widgets then convert from UCS-4 to UTF-8.
If not all UTF-8 bytes fit, they don't insert anything. Thus it is no
longer possible to get invalid UTF-8 by hitting the length limit.
It is unclear to me which charset is supposed to be used for strings
in internal buffers. I made BFU insert UTF-8 whenever CONFIG_UTF_8,
but form fields use the charset of the terminal; that may have to be
changed.
As a side effect, this change should solve bug 782, because
term_send_ucs no longer encodes in UTF-8 if CONFIG_UTF_8 is defined.
I think the UTF-8 and codepage encoding calls I added are safe, too.
A similar bug may still surface somewhere else, but 782 could be
closed for now.
This change also lays the foundation for binding actions to non-ASCII
keys, but the keystroke name parser doesn't yet support that.
The CONFIG_UTF_8 mode does not currently support non-ASCII characters
in hot keys, either.
To reproduce the bug before this patch:
Enable CONFIG_UTF_8, UTF-8 I/O, and UTF-8 charset.
Go to www.google.com and type "abc" in the text input field.
Then press Left. The cursor jumps to "a" when it should go to "c".
When the user presses enter during a text type-ahead search, simply cancel
the search without additionally following the current link. Link type-ahead
searching still will follow the active link on enter.
Make move_up and move_down return no value. Instead, save the old y value
and compare it to the new after calling move_up or move_down in
move_page_up or move_page_down, respectively.
This fixes a bug where if given a prefix, if that prefix specified a number
of pages greater than move-page-up actually scrolled, there would be no
screen update, because the last call to move_up would return FRAME_EVENT_OK
which would be returned from move_page_up, even tho move_page_up would have
previously returned FRAME_EVENT_REFRESH.
Don't try the key as an accesskey if a menu was opened, whether it was just
the main menu or whether it was a submenu of the menu menu (we would try
the key as an accesskey in the latter case).
In send_kbd_event, replace the KBD_MOD_ALT modifier when trying the key as
an accesskey rather than when we don't.
Instead of saving the old link colours when selecting a link and using that
to restore them when unselecting it, just copy the data from the document.
- Eliminate struct link_bg and the .link_bg and .link_bg_n members
of struct document_view.
- Eliminate the free_link routine and don't call it from draw_doc,
clear_link, or detach_formatted.
- Add a .old_current_link member to struct view_state and initialise it in
init_vs.
- Don't save link_bg in draw_current_link.
- Rewrite clear_link to use the document data instead of link_bg.
- Modify init_link_drawing not to allocate ling_bg and to return a pointer
to a static variable for the template character.
Including double-width glyph support.
Note: textarea is now drawn with blank collumn at end of lines. It seems
that this is more intuitive for users. It behaves similar as textareas in
graphical interfaces. I hope it will hold your interest.
+----+ +----+ +----+
|aaA | [right] |aaa_| [right] |aaa |
|aaa | |aaa | |Aaa |
|bb | |bb | |bb |
+----+ +----+ +----+
+----+ +----+ +----+
|Aaa | [end] |aaa_| [c] |aaa |
|aaa | |aaa | |Caa |
|bb | |bb | |abb |
+----+ +----+ +----+
A, _, C - cursor positions.
[right] - right arrow
[end] - ACT_END (End button)
[c] - Letter c.
Now this code:
<textarea rows="3" cols="3">aaaaaabb</textarea>
represents textarea with 3x3 positions for chars.
Before this texteare behaved some kind of weirdly. That code above was
rendered like this:
+----+
|aaaa|
|aabb|
|_ |
+----+
Thus, each caller must now choose the accelerator key and declare the
accelerator contexts (i.e. menus) to which it may add the command.
Also, use only one context for tab_menu.
These changes fix the following bugs in accelerator conflict detection:
* "~Pass frame URI to external command" may be displayed together
with "Pass tab URI to e~xternal command", but that was not
declared.
* "Pass link URI to e~xternal command" was declared as being in
the tab menu, but it is actually displayed in the link menu.
then dump_to_file_256 is defined in dump.c but not used.
If configure --enable-debug was used, then gcc warns about
the unused function, and the warning stops the build.
2. The description of document.dump.color_mode ends with a
newline, provoking a runtime warning from check_description
in src/config/options.c.
3. options.inc has preprocessor directives inside macro arguments.
That is not portable C. xgettext (GNU gettext-tools) 0.14.3 is
not smart enough to figure out the possible combinations, and
copies an incorrect string to elinks.pot.
Don't replace UTF-8 bytes with '*'. Probably there is need to do better
check what will be displayed.
Also get_current_link_title is no longer pretty and trivial. (o:
With commit 637f1e82e6 ('NET: Merge
change_connection into cancel_download'), cancel_download returns
immediately if the connection is not in a result state, so save some
code by not checking is_in_progress_state before calling cancel_download.
Commit 9cc9db4e24 broke submit buttons
on HTML forms, so that the server no longer knows which button was
actually pressed.
<kahmalo> The bug with forms seems to be that try_submit_given_form (in
src/viewer/text/link.c) is the only function that runs "onsubmit"
scripts, and it does not care which of the submit buttons was
pressed; it calls submit_given_form which submits based on the first
item of the form. [20:57]
<kahmalo> or last, I don't know how the list works.
<kahmalo> try_submit_given_form could get the control via
get_current_link(doc_view) but I suppose it'd be cleaner to provide
that as a parameter. [20:58]
Originally posted as:
<mid:87ek2heebh.fsf@Astalo.kon.iki.fi>
<nntp://news.gmane.org/87ek2heebh.fsf@Astalo.kon.iki.fi>
<http://permalink.gmane.org/gmane.comp.web.links/2745>
This simplifies unqueuing of downloads and makes it more obvious that
the 'change' being performed is to migrate or replace an old download
handle with a new one.
This changes the init target to be idempotent: most importantly it will now
never overwrite a Makefile if it exists. Additionally 'make init' will
generate the .vimrc files. Yay, no more stupid 'added fairies' commits! ;)
Revision 1.82 of src/scripting/lua/core.c and revision 1.42
of src/viewer/dump/dump.c (2 years, 2 months ago), which moved
add_document_to_string from the former to the latter, introduced
a logic error: the local variable pos was set in the outer loop,
which iterates thru the lines in the document, whereas it should be
(and had been) set in the inner loop, which iterates thru the columns.
This brings us all the way back to a working current_document_formatted
for Lua scripts.
Revision 1.147 (14 months, 2 weeks ago) broke the logic so that only
frame characters were added. This fixes that change, getting us halfway
back to a working current_document_formatted function for Lua.
the same accelerator key to multiple buttons in a dialog box or
to multiple items in a menu. ELinks already has some support for
this but it requires the translator to run ELinks and manually
scan through all menus and dialogs. The attached changes make it
possible to quickly detect and list any conflicts, including ones
that can only occur on operating systems or configurations that
the translator is not currently using.
The changes have no immediate effect on the elinks executable or
the MO files. PO files become larger, however.
The scheme works like this:
- Like before, accelerator keys in translatable strings are
tagged with the tilde (~) character.
- Whenever a C source file defines an accelerator key, it must
assign one or more named "contexts" to it. The translations in
the PO files inherit these contexts. If multiple strings use
the same accelerator (case insensitive) in the same context,
that's a conflict and can be detected automatically.
- The contexts are defined with "gettext_accelerator_context"
comments in source files. These comments delimit regions where
all translatable strings containing tildes are given the same
contexts. There must be one special comment at the top of the
region; it lists the contexts assigned to that region. The
region automatically ends at the end of the function (found
with regexp /^\}/), but it can also be closed explicitly with
another special comment. The comments are formatted like this:
/* [gettext_accelerator_context(foo, bar, baz)]
begins a region that uses the contexts "foo", "bar", and "baz".
The comma is the delimiter; whitespace is optional.
[gettext_accelerator_context()]
ends the region. */
The scripts don't currently check whether this syntax occurs
inside or outside comments.
- The names of contexts consist of C identifiers delimited with
periods. I typically used the name of a function that sets
up a dialog, or the name of an array where the items of a
menu are listed. There is a special feature for static
functions: if the name begins with a period, then the period
will be replaced with the name of the source file and a colon.
- If a menu is programmatically generated from multiple parts,
of which some are never used together, so that it is safe to
use the same accelerators in them, then it is necessary to
define multiple contexts for the same menu. link_menu() in
src/viewer/text/link.c is the most complex example of this.
- During make update-po:
- A Perl script (po/gather-accelerator-contexts.pl) reads
po/elinks.pot, scans the source files listed in it for
"gettext_accelerator_context" comments, and rewrites
po/elinks.pot with "accelerator_context" comments that
indicate the contexts of each msgid: the union of all
contexts of all of its uses in the source files. It also
removes any "gettext_accelerator_context" comments that
xgettext --add-comments has copied to elinks.pot.
- If po/gather-accelerator-contexts.pl does not find any
contexts for some use of an msgid that seems to contain an
accelerator (because it contains a tilde), it warns. If the
tilde refers to e.g. "~/.elinks" and does not actually mark
an accelerator, the warning can be silenced by specifying the
special context "IGNORE", which the script otherwise ignores.
- msgmerge copies the "accelerator_context" comments from
po/elinks.pot to po/*.po. Translators do not edit those
comments.
- During make check-po:
- Another Perl script (po/check-accelerator-contexts.pl) reads
po/*.po and keeps track of which accelerators have been bound
in each context. It warns about any conflicts it finds.
This script does not access the C source files; thus it does
not matter if the line numbers in "#:" lines are out of date.
This implementation is not perfect and I am not proposing to
add it to the main source tree at this time. Specifically:
- It introduces compile-time dependencies on Perl and Locale::PO.
There should be a configure-time or compile-time check so that
the new features are skipped if the prerequisites are missing.
- When the scripts include msgstr strings in warnings, they
should transcode them from the charset of the PO file to the
one specified by the user's locale.
- It is not adequately documented (well, except perhaps here).
- po/check-accelerator-contexts.pl reports the same conflict
multiple times if it occurs in multiple contexts.
- The warning messages should include line numbers, so that users
of Emacs could conveniently edit the conflicting part of the PO
file. This is not feasible with the current version of
Locale::PO.
- Locale::PO does not understand #~ lines and spews warnings
about them. There is an ugly hack to hide these warnings.
- Jonas Fonseca suggested the script could propose accelerators
that are still available. This has not been implemented.
There are three files attached:
- po/gather-accelerator-contexts.pl: Augments elinks.pot with
context information.
- po/check-accelerator-contexts.pl: Checks conflicts.
- accelerator-contexts.diff: Makes po/Makefile run the scripts,
and adds special comments to source files.
The menu shows a list of all fields of a form, with the possibility to jump
right to that form field when selecting an entry. The menu text is the
basic form field label "Radio button", "Text field", etc. with the form
field name or alt text as the right menu text.
It introduces a new main action called link-form-menu with no default
binding.
Requested by Klaus Knopper, as a mean to improve accessibility for complex,
overloaded pages like ebay.com.
