I didn’t respect the right order when I added the functions to move up and down
by half a page a few years ago.
Signed-off-by: Fabienne Ducroquet <fabiduc@gmail.com>
Use the same functions as for the list-style property since only the "type" part
of the list-style property is supported at this stage.
Signed-off-by: Fabienne Ducroquet <fabiduc@gmail.com>
* Rename P_STAR as P_DISC and P_PLUS as P_SQUARE.
* Delete P_NONE because it was used only as the default flag in init_html_parser
and a list with P_NONE then got bullets, so instead use P_DISC by default (as
per the CSS specification), and P_NO_BULLET for lists with no bullets.
* Use as bullets the characters:
- U+25E6 WHITE BULLET for the circle style;
- U+25AA BLACK SMALL SQUARE (alias square bullet) for the square style;
- U+2022 BULLET for the disc style (default).
Signed-off-by: Fabienne Ducroquet <fabiduc@gmail.com>
By default some Python warning messages would be written to standard error
by the interpreter. To prevent these warnings from making a mess of the
ELinks screen, all warnings were turned into exceptions so they could be
caught and displayed through the usual report_scripting_error() mechanism.
With Python 3.2, this approach backfires: A new class of ResourceWarnings
that are filtered by default (and hence would *not* have been written to
standard error) are now turned into exceptions, and these exceptions can't
be caught because they're emitted from the interpreter's cleanup code. As
a result, the uncaught exceptions would make a mess of the ELinks screen.
The new solution is to replace Python's standard library function
warnings.showwarning() with one that turns warning messages into exceptions.
This means we'll wait until a warning would have been written to standard
error before turning it into an exception, so other warnings that would
never have reached that point because they're filtered will remain unseen.
(The behavior of warning messages is described in the documentation for
the "warnings" module from Python's standard library.)
There was hardcoded 4096 for threads size, but below there was:
assertm(fd >= 0 && fd < FD_SETSIZE,
"get_handler: handle %d >= FD_SETSIZE %d",
fd, FD_SETSIZE);
if_assert_failed return NULL;
which fails for fd > 1024 (1024 was previous value of FD_SETSIZE)
DELETED:
* dumb {b}, smart {bb, bb_fr_en, bb_en_fr}: Redirects to Microsoft
Translator, which I can't get to work without JavaScript. Deleted.
* dumb {pyhelp}, smart {py, pydev}: Deleted as recommended by the
author of the CGI script.
* dumb {pyvault, lyrics}, smart {pyvault}: Can't find a new URL for the
service. Deleted.
* smart {gd}: Google Directory has been shut down. Deleted.
* smart {sd, sdc, sdu, sdp, sdj, whatis}: These don't seem to work
without JavaScript. Deleted.
* smart {id, draft}: The search still exists but I can't get it to
take the words from the URL. Deleted.
UPDATED:
* dumb {cia}: Had changed its URL, and the service is down, but they
intend to restore it. Updated and kept.
* dumb {lua}: ELinks no longer supports Lua 4.0. Changed to 5.1 as
installed by Debian.
* smart {cliki, foldoc, gwho, gwhat, gwhere, gwhen, a, imdb, wn, fsd,
rfcs, cr}: Updated URLs.
Each C function that can be called as a method of an ECMAScript object
is typically listed in a spidermonkeyFunctionSpec array and has a
comment that shows the name of the array and the name of the method.
For example, elinks_alert has a comment /* @elinks_funcs{"alert"} */
because elinks_funcs[] contains an element { "alert", elinks_alert, 1 }.
When some of those functions were split into outer and inner functions
for SpiderMonkey 1.8.5 compatibility, the comments were attached to
the inner functions, which contain the bulk of the code. Move the
comments to the outer functions, to which the array elements point.
Partially revert commits
a1c5fe51 (2011-05-08) bookmark_folder_get_property: xulrunner-2.0 fix
e86ec567 (2012-03-04) Compilation fixes (--enable-debug)
jsval_to_bookmark_string once again takes jsval val, rather than jsid id.
This way, bookmark_set_property does not have to call JS_ValueToId,
which would needlessly intern the new string value of the property,
i.e. the title or the URI. Instead, bookmark_folder_get_property
has to call JS_IdToValue.
forms_item declared a variable (jsval val), passed its address to
forms_item2, and set it as the return value. However, forms_item2
could return without initializing the jsval, especially if given too
many arguments. Fix by initializing to JSVAL_VOID right away.
I'm not sure that is the correct value to return in such cases,
but at least it's better than risking a crash.
Likewise in form_elements_item and form_elements_namedItem.
Fix this warning:
Generating docs for page todo...
todo:12: warning: explicit link request to 'url' could not be resolved
The #url syntax was supposed to refer to the url member of the
containing structure, but it apparently doesn't work when @todo
copies the paragraph to a separate page.
Doxygen warned that <uri> is an unsupported xml/html tag.
It was not intended as a tag though; rather as a placeholder
akin to <var>uri</var>. Escape with a backslash.
In almost all calls to parse_header, the second argument is a string
literal: parse_header(head, "Charset", NULL) for example.
Of course, parse_header does not write to that string. Accordingly,
make the parameter point to const, so calls that use a variable rather
than a string literal can make that variable point to const too.
Leaving the other parameters non-const for now.
http_negotiate_parse_data passed &token->length as the int *outlen
parameter of base64_decode_bin, which stores an int at that location.
However, gss_buffer_desc::length is size_t in all implementations that
I checked: MIT Kerberos Version 5 Release 1.10, libgssglue 0.4, and
GNU GSS 1.0.2. This mismatch could cause the build to fail:
.../src/protocol/http/http_negotiate.c: In function ‘http_negotiate_parse_data’:
.../src/protocol/http/http_negotiate.c:173:2: error: passing argument 3 of ‘base64_decode_bin’ from incompatible pointer type [-Werror]
In file included from .../src/protocol/http/http_negotiate.c:30:0:
.../src/util/base64.h:8:16: note: expected ‘int *’ but argument is of type ‘size_t *’
On 64-bit big-endian hosts, it might also cause the GSSAPI
implementation to read too much data from memory and disclose it to
some network server, or crash ELinks.
(cherry picked from elinks-0.12 commit d33c807dd9)
