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)] */
|
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"
|
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 "
|
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"
|
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"
|
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")),
|
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.")),
|
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.")),
|
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 "
|
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.")),
|
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.")),
|
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 "
|
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 "
|
2006-09-02 10:50:53 -04:00
|
|
|
"in the style of e.g. http4://elinks.cz/.")),
|
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. "
|
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 "
|
2006-09-02 10:50:53 -04:00
|
|
|
"in the style of e.g. http4://elinks.cz/.")),
|
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 "
|
2006-09-02 10:50:53 -04:00
|
|
|
"in the style of e.g. http6://elinks.cz/.")),
|
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, "
|
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.")),
|
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"
|
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.")),
|
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.")),
|
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\".")),
|
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")),
|
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")),
|
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")),
|
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.")),
|
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.")),
|
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 "
|
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.")),
|
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.")),
|
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.")),
|
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"
|
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 "
|
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.")),
|
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.")),
|
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 "
|
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.")),
|
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.")),
|
2005-09-15 09:58:31 -04:00
|
|
|
|
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.")),
|
|
|
|
|
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.")),
|
2005-09-15 09:58:31 -04:00
|
|
|
|
2009-05-21 10:22:12 -04:00
|
|
|
#ifdef CONFIG_TRE
|
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.")),
|
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.")),
|
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"
|
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")),
|
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.")),
|
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.")),
|
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.")),
|
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'.")),
|
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.)")),
|
2005-09-15 09:58:31 -04:00
|
|
|
|
2006-11-03 13:56:55 -05:00
|
|
|
/* FIXME: Write more. */
|
2006-11-03 21:23:22 -05:00
|
|
|
INIT_OPT_INT("document.cache", N_("Revalidation interval"),
|
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"
|
2007-02-28 15:22:40 -05:00
|
|
|
"A value of -1 disables automatic revalidation.")),
|
2006-10-26 05:53:30 -04:00
|
|
|
|
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 "
|
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"
|
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.")),
|
2005-09-15 09:58:31 -04:00
|
|
|
|
|
|
|
INIT_OPT_BOOL("document.colors", N_("Ensure contrast"),
|
|
|
|
"ensure_contrast", 0, 1,
|
2008-01-26 23:09:18 -05:00
|
|
|
N_("Makes sure that the back- and foreground colors are never "
|
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.")),
|
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 "
|
2005-09-15 09:58:31 -04:00
|
|
|
"a codepage determined by a selected locale.")),
|
|
|
|
|
2006-03-13 13:06:02 -05:00
|
|
|
INIT_OPT_INT("document.dump", N_("Color mode"),
|
2006-12-25 04:51:24 -05:00
|
|
|
"color_mode", 0, -1, COLOR_MODES - 1, -1,
|
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"
|
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"
|
2007-01-06 16:36:45 -05:00
|
|
|
"The color modes are:\n"
|
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"
|
2007-01-06 16:36:45 -05:00
|
|
|
"4 is true color mode")),
|
2006-12-25 04:51:24 -05:00
|
|
|
|
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 "
|
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).")),
|
|
|
|
|
2008-01-26 23:09:18 -05:00
|
|
|
INIT_OPT_INT("document.html", N_("Rendering of HTML link element"),
|
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 |