aniani/elinks
1
0
Fork 0
mirror of https://github.com/rkd77/elinks.git synced 2024-11-04 08:17:17 -05:00
Code
7e8c95d934
elinks/src/config/options.inc

1435 lines
51 KiB
PHP
Raw Normal View History

Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Option definitions. */
/* TODO: Autogenerate this file from something more human readable. --jonas */
/* TODO: Make #ifdef FEATURE more consistent. */
/* A few guidelines for this file: */
/* 1. Keep options in alphabetical order with trees as the first children
* of their parents.
* 2. Keep in mind that descriptions should be readable on 80 wide terminals
* so insert appropriate line breaks and newlines.
* 3. If several command line options should share the same caption and
* description they should be declared after another and only the last one
* should have the caption and description defined. (ie. -h, -? and -help)
* 4. When adding an alias put a comment about the date the alias was added.
* 5. Love thy option system! :) */
static struct option_info config_options_info[] = {
Here is a framework that detects cases where a PO file assigns 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.
2005-12-04 18:38:29 -05:00
/* [gettext_accelerator_context(IGNORE)] */
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("", N_("Configuration system"),
"config", 0,
N_("Configuration handling options.")),
INIT_OPT_INT("config", N_("Comments"),
"comments", 0, 0, 3, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Amount of comments automatically written to the config "
"file:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 is no comments are written\n"
"1 is only the \"blurb\" (name+type) is written\n"
"2 is only the description is written\n"
"3 is full comments are written")),
INIT_OPT_INT("config", N_("Indentation"),
"indentation", 0, 0, 16, 2,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Shift width of one indentation level in the configuration "
"file. Zero means that no indentation is performed at all "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"when saving the configuration.")),
INIT_OPT_INT("config", N_("Saving style"),
"saving_style", 0, 0, 3, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Determines what happens when you tell ELinks to save "
"options:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 is only values of current options are altered\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"1 is values of current options are altered and missing\n"
" options are added at the end of the file\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"2 is the configuration file is rewritten from scratch\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"3 is values of current options are altered and missing\n"
" options CHANGED during this ELinks session are added at\n"
" the end of the file")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("config", N_("Comments localization"),
"i18n", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("If set to 1, comments in the configuration file will be "
"translated to the language used by UI. Note that if you have "
"different language set in different terminals, the language "
"used in the configuration file MAY be the same as on the "
"terminal where you saved the file, but it should be "
"generally considered unpredictable.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("config", N_("Saving style warnings"),
"saving_style_w", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("This is internal option used when displaying a warning "
"about obsolete config.saving_style. You shouldn't touch "
"it.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("config", N_("Show template"),
"show_template", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Show template options in autocreated trees in the options "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"manager and save them to the configuration file.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("Connections"),
"connection", OPT_SORT,
N_("Connection options.")),
INIT_OPT_BOOL("connection", N_("Asynchronous DNS"),
"async_dns", 0, 1,
N_("Whether to use asynchronous DNS resolving.")),
INIT_OPT_INT("connection", N_("Maximum connections"),
"max_connections", 0, 1, 16, 10,
N_("Maximum number of concurrent connections.")),
INIT_OPT_INT("connection", N_("Maximum connections per host"),
"max_connections_to_host", 0, 1, 8, 2,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Maximum number of concurrent connections to a given "
"host.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("connection", N_("Connection retries"),
"retries", 0, 0, 16, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of tries to establish a connection. "
"Zero means try forever.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("connection", N_("Receive timeout"),
"receive_timeout", 0, 1, 1800, 120,
N_("Receive timeout (in seconds).")),
#ifdef CONFIG_IPV6
INIT_OPT_BOOL("connection", N_("Try IPv4 when connecting"),
"try_ipv4", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to try to connect to a host over IPv4. "
"Note that if connection.try_ipv6 is enabled too, "
"it takes precedence. And better do not touch this "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"at all unless you are sure what are you doing.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
"Note that you can also force a given protocol "
"to be used on a per-connection basis by using a URL "
Change elinks.or.cz to elinks.cz and one i.e. to e.g. in option docs. Some other instances of elinks.or.cz still remain in the tree.
2006-09-02 10:50:53 -04:00
"in the style of e.g. http4://elinks.cz/.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#else
INIT_OPT_BOOL("connection", N_("Try IPv4 when connecting"),
"try_ipv4", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to try to connect to a host over IPv4. "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"Do not touch this option.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
"Note that you can also force a given protocol "
"to be used on a per-connection basis by using a URL "
Change elinks.or.cz to elinks.cz and one i.e. to e.g. in option docs. Some other instances of elinks.or.cz still remain in the tree.
2006-09-02 10:50:53 -04:00
"in the style of e.g. http4://elinks.cz/.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#endif
#ifdef CONFIG_IPV6
INIT_OPT_BOOL("connection", N_("Try IPv6 when connecting"),
"try_ipv6", 0, 1,
N_("Whether to try to connect to a host over IPv6.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
"Note that you can also force a given protocol "
"to be used on a per-connection basis by using a URL "
Change elinks.or.cz to elinks.cz and one i.e. to e.g. in option docs. Some other instances of elinks.or.cz still remain in the tree.
2006-09-02 10:50:53 -04:00
"in the style of e.g. http6://elinks.cz/.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#endif
INIT_OPT_INT("connection", N_("Timeout for non-restartable connections"),
"unrestartable_receive_timeout", 0, 1, 1800, 600,
N_("Timeout for non-restartable connections (in seconds).")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("Document"),
"document", OPT_SORT,
N_("Document options.")),
INIT_OPT_TREE("document", N_("Browsing"),
"browse", 0,
N_("Document browsing options (mainly interactivity).")),
INIT_OPT_TREE("document.browse", N_("Access keys"),
"accesskey", 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Options for handling of link access keys. "
"An HTML document can use the ACCESSKEY attribute to assign "
"an access key to an element. When an access key is pressed, "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"the corresponding element will be given focus.")),
INIT_OPT_BOOL("document.browse.accesskey", N_("Automatic links following"),
"auto_follow", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Automatically follow a link or submit a form if "
"appropriate accesskey is pressed - this is the standard "
"behaviour, but it's considered dangerous.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.accesskey", N_("Display access key in link info"),
"display", 0, 0,
N_("Display access key in link info.")),
INIT_OPT_INT("document.browse.accesskey", N_("Accesskey priority"),
"priority", 0, 0, 2, 0,
N_("Priority of 'accesskey' HTML attribute:\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"0 is first try all normal bindings; if it fails,\n"
" check accesskey\n"
"1 is first try only frame bindings; if it fails,\n"
" check accesskey\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"2 is first check accesskey (this can be dangerous)")),
INIT_OPT_TREE("document.browse", N_("Forms"),
"forms", 0,
N_("Options for handling of the forms interaction.")),
INIT_OPT_BOOL("document.browse.forms", N_("Submit form automatically"),
"auto_submit", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Automagically submit a form when enter is pressed with a "
"text field selected.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.forms", N_("Confirm submission"),
"confirm_submit", 0, 1,
N_("Ask for confirmation when submitting a form.")),
INIT_OPT_INT("document.browse.forms", N_("Default form input size"),
"input_size", 0, 3, 300, HTML_DEFAULT_INPUT_SIZE,
N_("Default form input size if none is specified.")),
INIT_OPT_BOOL("document.browse.forms", N_("Insert mode"),
"insert_mode", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("The setting for this option affects how key presses are "
"handled when one selects a text-input form-field. When "
"enabled, one must explicitly 'enter' a selected text-field "
"to edit it; this prevents text fields from capturing key "
"presses, such as presses of a scroll key, when it is "
"inadvertently selected. When disabled, key presses are "
"always inserted into a selected text field.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_STRING("document.browse.forms", N_("External editor"),
"editor", 0, "",
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Path to the executable that ELinks should launch when the "
"user requests to edit a textarea with an external editor.\n"
"\n"
"If this is blank, ELinks will use the value of the "
"environmental variable $EDITOR. If $EDITOR is empty or not "
"set, ELinks will then default to \"vi\".")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Images"),
"images", 0,
N_("Options for handling of images.")),
INIT_OPT_INT("document.browse.images", N_("Display style for image tags"),
"display_style", 0, 0, 3, 2,
N_("Display style for image tags when displayed:\n"
"0 means always display IMG\n"
"1 means always display filename\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"2 means display alt/title attribute if possible,\n"
" IMG if not\n"
"3 means display alt/title attribute if possible,\n"
" filename if not")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.images", N_("Maximum length for image filename"),
"filename_maxlen", 0, 0, 500, 0,
N_("Maximum length of image filename when displayed:\n"
"0 means always display full filename\n"
"1-500 means display filename with this maximal length;\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
" if it is longer, the middle is substituted by\n"
" an asterisk")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Compatibility aliases. Added: 2004-12-15, 0.10pre3.CVS. It was
* replaced by display_style and filename_maxlen options combination. */
INIT_OPT_ALIAS("document.browse.images", "file_tags", 0,
"document.browse.images.filename_maxlen"),
INIT_OPT_INT("document.browse.images", N_("Image links tagging"),
"image_link_tagging", 0, 0, 2, 1,
N_("When to enclose image links:\n"
"0 means never\n"
"1 means never if alt or title are provided (old behavior)\n"
"2 means always")),
INIT_OPT_STRING("document.browse.images", N_("Image link prefix"),
"image_link_prefix", 0, "[",
N_("Prefix string to use to mark image links.")),
INIT_OPT_STRING("document.browse.images", N_("Image link suffix"),
"image_link_suffix", 0, "]",
N_("Suffix string to use to mark image links.")),
INIT_OPT_INT("document.browse.images", N_("Maximum length for image label"),
"label_maxlen", 0, 0, 500, 0,
N_("Maximum length of image label (alt/title):\n"
"0 means always display full label\n"
"1-500 means display label with this maximal length;\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
" if it is longer, the middle is substituted by\n"
" an asterisk")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.images", N_("Display links to images w/o alt"),
"show_as_links", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Display links to images without an alt attribute. If this "
"option is off, these images are completely invisible.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.images", N_("Display links to images"),
"show_any_as_links", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Display links to any images in the document, regardless "
"of them having an alt attribute or not. If this option is "
"off, the alt attribute contents is shown, but as normal "
"text, not selectable as a link.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Links"),
"links", 0,
N_("Options for handling of links to other documents.")),
INIT_OPT_TREE("document.browse.links", N_("Active link"),
"active_link", 0,
N_("Options for the active link.")),
INIT_OPT_TREE("document.browse.links.active_link", N_("Colors"),
"colors", 0,
N_("Active link colors.")),
INIT_OPT_COLOR("document.browse.links.active_link.colors", N_("Background color"),
"background", 0, "#0000ff",
N_("Default background color.")),
INIT_OPT_COLOR("document.browse.links.active_link.colors", N_("Text color"),
"text", 0, "black",
N_("Default text color.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Enable color"),
"enable_color", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Enable use of the active link background and text color "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"settings instead of the link colors from the document.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Bold"),
"bold", 0, 0,
N_("Make the active link text bold.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Invert colors"),
"invert", 0, 1,
N_("Invert the fore- and background color so the link "
"stands out.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Underline"),
"underline", 0, 0,
N_("Underline the active link.")),
INIT_OPT_BOOL("document.browse.links", N_("Directory highlighting"),
"color_dirs", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Highlight links to directories in FTP and local directory "
"listing.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.links", N_("Number links"),
"numbering", 0, 0,
N_("Display numbers next to the links.")),
INIT_OPT_INT("document.browse.links", N_("Handling of target=_blank"),
"target_blank", 0, 0, 3, 0,
N_("Define how to handle links having target=_blank set:\n"
"0 means open link in current tab\n"
"1 means open link in new tab in foreground\n"
"2 means open link in new tab in background\n"
"3 means open link in new window")),
/* Compatibility aliases. Added: 2004-01-07, 0.9.0.CVS. */
INIT_OPT_ALIAS("document.browse.links", "typeahead_wraparound", 0,
"document.browse.search.wraparound"),
INIT_OPT_ALIAS("document.browse.links", "typeahead_error", 0,
"document.browse.search.show_not_found"),
INIT_OPT_BOOL("document.browse.links", N_("Use tabindex"),
"use_tabindex", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to navigate links using tabindex specified "
"ordering. The TABINDEX attribute in HTML elements specifies "
"the order in which links should receive focus when using the "
"keyboard to navigate the document.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.links", N_("Missing fragment reporting"),
"missing_fragment", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Open a message box when document has no tag with given "
"id.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.links", N_("Number keys select links"),
"number_keys_select_link", 0, 0, 2, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number keys select links rather than specify command "
"prefixes. This is a tristate:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 means never\n"
"1 means if document.browse.links.numbering = 1\n"
"2 means always")),
INIT_OPT_BOOL("document.browse.links", N_("Warn about maliciously crafted URIs"),
"warn_malicious", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("When following a link the user ID part of the URI is "
"checked and if a maliciously crafted URI is detected a "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"warning dialog will ask before following the link.")),
/* TODO - this is somehow implemented by ff, but disabled
* for now as it doesn't work. */
INIT_OPT_BOOL("document.browse.links", N_("Wrap-around links cycling"),
"wraparound", /* 0 */ 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("When pressing 'down' on the last link, jump to the first "
"one, and vice versa.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Scrolling"),
"scrolling", OPT_SORT,
N_("Scrolling options.")),
INIT_OPT_INT("document.browse.scrolling", N_("Horizontal step"),
"horizontal_step", 0, 1, 9999, 8,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of columns to scroll when a key bound to "
"scroll-left or scroll-right is pressed and no prefix was "
"given.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.scrolling", N_("Extended horizontal scrolling"),
"horizontal_extended", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to allow horizontal scrolling when the document "
"does not extend off the screen. Useful for copy/paste "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"operations.")),
INIT_OPT_INT("document.browse.scrolling", N_("Margin"),
"margin", 0, 0, 20, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Size of the virtual margin - when you click inside of "
"that margin, document scrolls in that direction.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.scrolling", N_("Vertical step"),
"vertical_step", 0, 1, 9999, 2,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of lines to scroll when a key bound to scroll-up "
"or scroll-down is pressed and no prefix was given.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Add document.browse.scrolling.vertical_overlap Add an option to specify the number of overlapping lines when scrolling page by page (0 by default because this is ELinks' current behaviour). Signed-off-by: Fabienne Ducroquet <fabiduc@gmail.com>
2010-08-14 15:24:21 -04:00
INIT_OPT_INT("document.browse.scrolling", N_("Vertical overlap"),
"vertical_overlap", 0, 0, 10, 0,
N_("Number of overlapping lines between the new page displayed "
"and the previous one when scrolling one page up or down.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Searching"),
"search", 0,
N_("Options for searching.")),
INIT_OPT_BOOL("document.browse.search", N_("Case sensitivity"),
"case", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether the search should match the document text while "
"maintaining case sensitivity.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
TRE: Check for 32-bit wchar_t at configure time 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.
2009-05-21 10:22:12 -04:00
#ifdef CONFIG_TRE
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.search", N_("Regular expressions"),
"regex", 0, 0, 2, 0,
N_("Enable searching with regular expressions:\n"
"0 for plain text searching\n"
"1 for basic regular expression searches\n"
"2 for extended regular expression searches")),
#endif
INIT_OPT_BOOL("document.browse.search", N_("Show search hit top or bottom dialogs"),
"show_hit_top_bottom", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to show a dialog when the search hits the top or "
"bottom of the document.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.search", N_("Wraparound"),
"wraparound", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Wrap around when searching. Currently only used for "
"typeahead.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.search", N_("Show not found"),
"show_not_found", 0, 0, 2, 2,
N_("How to inform the user when nothing is matched:\n"
"0 means do nothing\n"
"1 means beep the terminal\n"
"2 means pop up message box")),
INIT_OPT_INT("document.browse.search", N_("Typeahead searching"),
"typeahead", 0, 0, 2, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Start typeahead searching when an unbound key is pressed "
"without any modifiers. Note that most keys have default "
"bindings, so this feature will not be useful unless you "
"unbind them.\n"
"\n"
"0 disables this feature; typeahead searching will only be\n"
" used when you press a key bound to search-typeahead or\n"
" similar\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"1 automatically starts typeahead searching thru link text\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"2 automatically starts typeahead searching thru all document\n"
" text")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse", N_("Horizontal text margin"),
"margin_width", 0, 0, 9, 3,
N_("Horizontal text margin.")),
INIT_OPT_BOOL("document.browse", N_("Document meta refresh"),
"refresh", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Automatically follow document-specified refresh "
"directives ('<meta> refresh' tags). Web-page authors use "
"these to instruct the browser to reload a document at a "
"given interval or to load another page. Regardless of the "
"value the refresh URI is accessible as a link.\n"
"\n"
"Use the document.browse.minimum_refresh_time to control the "
"minimum number of seconds a refresh will wait.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse", N_("Document meta refresh minimum time"),
"minimum_refresh_time", 0, 0, INT_MAX, 1000,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("The minimum number of milliseconds that should pass "
"before refreshing. If set to zero the document refresh time "
"is used unchanged. It can fix going back in history for some "
"sites that use refreshing with zero values.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse", N_("Tables navigation order"),
"table_move_order", 0, 0,
N_("Move by columns in table, instead of rows.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("document", N_("Cache"),
"cache", OPT_SORT,
N_("Cache options.")),
INIT_OPT_BOOL("document.cache", N_("Cache information about redirects"),
"cache_redirects", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Cache even redirects sent by server (usually thru HTTP by "
"a 302 HTTP code and a Location header). This was the "
"original behaviour for quite some time, but it causes "
"problems in a situation very common to various web login "
"systems - frequently, when accessing a certain location, "
"they will redirect you to a login page if they don't receive "
"an auth cookie, the login page then gives you the cookie and "
"redirects you back to the original page, but there you have "
"already cached redirect back to the login page! If this "
"option has value of 0, this malfunction is fixed, but "
"occasionally you may get superfluous (depends on how you "
"take it ;-) requests to the server. If this option has value "
"of 1, experienced users can still workaround it by clever "
"combination of usage of reload, jumping around in session "
"history and hitting ctrl+enter.\n"
"\n"
"Note that this option is checked when retrieving the "
"information from cache, not when saving it to cache - thus "
"if you enable it, even previous redirects will be taken from "
"cache instead of asking the server.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.cache", N_("Ignore cache-control info from server"),
"ignore_cache_control", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Ignore Cache-Control and Pragma server headers. "
"When set, the document is cached even with 'Cache-Control: "
"no-cache'.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.cache", N_("Formatted documents"),
"format", 0,
N_("Format cache options.")),
INIT_OPT_INT("document.cache.format", N_("Number"),
"size", 0, 0, 256, 5,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of cached formatted pages. Do not get too "
"generous here, 'formatted' means that all the accompanying "
"structures are kept in memory so that you get the cached "
"document immediatelly, but these structures may take a lot "
"- 2x the size of the HTML source is probably not unusual, "
"but it can be even more if the document consists of a lot "
"of short lines (padded right, if possible) and links and "
"not much other markup. So if you set this to 256 and then "
"you don't like your ELinks eating 90M, don't come "
"complaining to us. ;-)\n"
"\n"
"Also note that the format cache itself is not counted to "
"the memory cache size, but the HTML source of the formatted "
"documents is always cached, even if it is over the memory "
"cache size threshold. (Then of course no other documents "
"can be cached.)")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Support for document.cache.interval (set it to -1) and rename it ...to document.cache.revalidation_interval. Moreover, -1 is the default now.
2006-11-03 13:56:55 -05:00
/* FIXME: Write more. */
Rewrite the description for document.cache.revalidation_interval again
2006-11-03 21:23:22 -05:00
INIT_OPT_INT("document.cache", N_("Revalidation interval"),
Fix wrongly placed -1 ;-)
2006-11-03 14:19:43 -05:00
"revalidation_interval", 0, -1, 86400, -1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Period in seconds that a cache entry is considered to be "
"up-to-date. When a document is loaded and this interval has "
"elapsed since the document was initially loaded or most "
"recently revalidated with the server, the server will be "
"checked in case there is a more up-to-date version of the "
"document.\n"
"\n"
document.cache.revalidation_interval: document that a value of -1 disables automatic revalidation
2007-02-28 15:22:40 -05:00
"A value of -1 disables automatic revalidation.")),
"If-Modified-Since" second approach. 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.
2006-10-26 05:53:30 -04:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.cache", N_("Memory cache"),
"memory", 0,
N_("Memory cache options.")),
INIT_OPT_LONG("document.cache.memory", N_("Size"),
"size", 0, 0, LONG_MAX, 1048576,
N_("Memory cache size (in bytes).")),
INIT_OPT_TREE("document", N_("Charset"),
"codepage", 0,
N_("Charset options.")),
INIT_OPT_CODEPAGE("document.codepage", N_("Default codepage"),
"assume", 0, "System",
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Default document codepage. 'System' stands for "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"a codepage determined by a selected locale.")),
INIT_OPT_BOOL("document.codepage", N_("Ignore charset info from server"),
"force_assumed", 0, 0,
N_("Ignore charset info sent by server.")),
INIT_OPT_TREE("document", N_("Default color settings"),
"colors", 0,
N_("Default document color settings.")),
INIT_OPT_COLOR("document.colors", N_("Text color"),
"text", 0, "#bfbfbf",
N_("Default text color.")),
INIT_OPT_COLOR("document.colors", N_("Background color"),
"background", 0, "#000000",
N_("Default background color.")),
INIT_OPT_COLOR("document.colors", N_("Link color"),
"link", 0, "#0000ff",
N_("Default link color.")),
INIT_OPT_COLOR("document.colors", N_("Visited-link color"),
"vlink", 0, "#ffff00",
N_("Default visited link color.")),
INIT_OPT_COLOR("document.colors", N_("Image-link color"),
"image", 0, "darkolivegreen",
N_("Default image link color.")),
INIT_OPT_COLOR("document.colors", N_("Bookmarked-link color"),
"bookmark", 0, "hotpink",
N_("Default bookmarked link color.")),
INIT_OPT_COLOR("document.colors", N_("Directory color"),
"dirs", 0, "#ffff00",
N_("Default directory color.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"See document.browse.links.color_dirs option.")),
/* Compatibility alias: added by jonas at 2005-05-31, 0.11.CVS. */
INIT_OPT_ALIAS("document.colors", "allow_dark_on_black", OPT_ALIAS_NEGATE,
"document.colors.increase_contrast"),
INIT_OPT_BOOL("document.colors", N_("Increase contrast"),
"increase_contrast", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Increase the contrast between the foreground and "
"background colors to ensure readability. For example it "
"disallows dark colors on a black background. Note, this "
"is different from ensuring the contrast with the "
"ensure_contrast option.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.colors", N_("Ensure contrast"),
"ensure_contrast", 0, 1,
Strings corrections from Malcolm Parsons Fix the spelling and grammar in various comments, variable names, comment descriptions, and documentation.
2008-01-26 23:09:18 -05:00
N_("Makes sure that the back- and foreground colors are never "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"equal.")),
/* If you change this please also change ACT_MAIN_DOCUMENT_COLORS action
* handling. */
INIT_OPT_INT("document.colors", N_("Use document-specified colors"),
"use_document_colors", 0, 0, 2, 2,
N_("Use colors specified in document:\n"
"0 is use always the default settings\n"
"1 is use document colors if available, except background\n"
"2 is use document colors, including background. This can\n"
" mostly look very impressive, but some sites will appear\n"
" really ugly. Note, that obviously if the background is\n"
" not black, it will break the behaviour of transparency.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("document", N_("Downloading"),
"download", 0,
N_("Options regarding files downloading and handling.")),
INIT_OPT_STRING("document.download", N_("Default download directory"),
"directory", 0, "./",
N_("Default download directory.")),
INIT_OPT_BOOL("document.download", N_("Set original time"),
"set_original_time", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Set the timestamp of each downloaded file to the "
"timestamp stored on the server.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Does automatic resuming make sense as an option? */
INIT_OPT_INT("document.download", N_("Prevent overwriting"),
"overwrite", 0, 0, 2, 2,
N_("Prevent overwriting the local files:\n"
"0 is files will silently be overwritten\n"
"1 is add a suffix .{number} (for example '.1') to the name\n"
"2 is ask the user")),
INIT_OPT_INT("document.download", N_("Notify download completion by bell"),
"notify_bell", 0, 0, 2, 0,
N_("Audio notification when download is completed:\n"
"0 is never\n"
"1 is when background notification is active\n"
"2 is always")),
INIT_OPT_TREE("document", N_("Dump output"),
"dump", 0,
N_("Dump output options.")),
INIT_OPT_CODEPAGE("document.dump", N_("Codepage"),
"codepage", 0, "System",
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Codepage used in dump output. 'System' stands for "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"a codepage determined by a selected locale.")),
1. If neither CONFIG_88_COLORS nor CONFIG_256_COLORS is defined, 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.
2006-03-13 13:06:02 -05:00
INIT_OPT_INT("document.dump", N_("Color mode"),
Bug 871, 752: Lock down enum color_mode and change option help to match. The numbering of document.dump.color_mode and terminal._template_.colors is now the same regardless of compile-time options, unlike in previous versions. Therefore this version of ELinks may interpret a configuration file differently from previous versions even if compiled with the same options. This is unfortunate but the alternatives (keeping the numbering dependent on configuration options; defining separate options that use the new numbering; starting the numbers from 10 or so and recognizing the previous ones only for compatibility) seem even worse.
2006-12-25 04:51:24 -05:00
"color_mode", 0, -1, COLOR_MODES - 1, -1,
Bug 752: Rearrange the docstrings of color-mode options. 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.
2007-01-06 16:36:45 -05:00
/* The list of modes must be at the end of this string
* because AsciiDoc 7.1.2 does not support continuing
* an outer list entry after an inner list.
* TRANSLATORS: This restriction applies only to the
* "en" (English) translation. (See doc/Makefile.) */
N_("Color mode for dumps.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Bug 752: Rearrange the docstrings of color-mode options. 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.
2007-01-06 16:36:45 -05:00
"Some modes may have been disabled at compile time. "
"The Setup -> Terminal options dialog lists the modes "
"supported by this executable. If you select an "
"unsupported mode, ELinks uses 16 colors.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Bug 752: Rearrange the docstrings of color-mode options. 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.
2007-01-06 16:36:45 -05:00
"The color modes are:\n"
True color mode. See new konsole. TODO: dump
2006-08-19 17:39:40 -04:00
"-1 is standard dump mode\n"
"0 is mono mode\n"
"1 is 16 color mode\n"
"2 is 88 color mode\n"
"3 is 256 color mode\n"
Bug 752: Rearrange the docstrings of color-mode options. 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.
2007-01-06 16:36:45 -05:00
"4 is true color mode")),
Bug 871, 752: Lock down enum color_mode and change option help to match. The numbering of document.dump.color_mode and terminal._template_.colors is now the same regardless of compile-time options, unlike in previous versions. Therefore this version of ELinks may interpret a configuration file differently from previous versions even if compiled with the same options. This is unfortunate but the alternatives (keeping the numbering dependent on configuration options; defining separate options that use the new numbering; starting the numbers from 10 or so and recognizing the previous ones only for compatibility) seem even worse.
2006-12-25 04:51:24 -05:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_STRING("document.dump", N_("Footer"),
"footer", 0, "",
N_("Footer string used in dumps. %u is substituted by URL.")),
INIT_OPT_STRING("document.dump", N_("Header"),
"header", 0, "",
N_("Header string used in dumps. %u is substituted by URL.")),
INIT_OPT_BOOL("document.dump", N_("Numbering"),
"numbering", 0, 1,
N_("Whether to print link numbers in dump output.")),
INIT_OPT_BOOL("document.dump", N_("References"),
"references", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to print references (URIs) of document links "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"in dump output.")),
INIT_OPT_STRING("document.dump", N_("Separator"),
"separator", 0, "\n\n",
N_("String which separates two dumps.")),
INIT_OPT_INT("document.dump", N_("Width"),
"width", 0, 1, 65536, DEFAULT_TERMINAL_WIDTH,
N_("Width of screen in characters when dumping documents.")),
INIT_OPT_TREE("document", N_("History"),
"history", OPT_SORT,
N_("History options.")),
INIT_OPT_BOOL("document.history", N_("Keep unhistory"),
"keep_unhistory", 0, 1,
N_("Keep unhistory (\"forward history\").")),
INIT_OPT_TREE("document", N_("HTML rendering"),
"html", 0,
N_("Options concerning the display of HTML pages.")),
INIT_OPT_BOOL("document.html", N_("Display frames"),
"display_frames", 0, 1,
N_("Display frames.")),
INIT_OPT_BOOL("document.html", N_("Display tables"),
"display_tables", 0, 1,
N_("Display tables.")),
INIT_OPT_BOOL("document.html", N_("Display subscripts"),
"display_subs", 0, 1,
N_("Display subscripts (as [thing]).")),
INIT_OPT_BOOL("document.html", N_("Display superscripts"),
"display_sups", 0, 1,
N_("Display superscripts (as ^thing).")),
Strings corrections from Malcolm Parsons Fix the spelling and grammar in various comments, variable names, comment descriptions, and documentation.
2008-01-26 23:09:18 -05:00
INIT_OPT_INT("document.html", N_("Rendering of HTML link element"),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"link_display", 0, 0, 5, 2,
N_("How to render <link> tags from the HTML header:\n"
"0 is nothing\n"
"1 is title\n"
"2 is name in addition\n"
"3 is hreflang in addition\n"
"4 is type in addition\n"
"5 is everything")),
INIT_OPT_BOOL("document.html", N_("Underline links"),
"underline_links