aniani/elinks
1
0
Fork 0
mirror of https://github.com/rkd77/elinks.git synced 2024-12-04 14:46:47 -05:00
Code
be719e1ac1
elinks/src/config/options.inc

1467 lines
52 KiB
PHP
Raw Normal View History

Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Option definitions. */
/* TODO: Autogenerate this file from something more human readable. --jonas */
/* TODO: Make #ifdef FEATURE more consistent. */
/* A few guidelines for this file: */
/* 1. Keep options in alphabetical order with trees as the first children
* of their parents.
* 2. Keep in mind that descriptions should be readable on 80 wide terminals
* so insert appropriate line breaks and newlines.
* 3. If several command line options should share the same caption and
* description they should be declared after another and only the last one
* should have the caption and description defined. (ie. -h, -? and -help)
* 4. When adding an alias put a comment about the date the alias was added.
* 5. Love thy option system! :) */
bug 764: Initialize the right member of union option_value INIT_OPTION used to initialize union option_value at compile time by casting the default value to LIST_OF(struct option) *, which is the type of the first member. On sparc64 and other big-endian systems where sizeof(int) < sizeof(struct list_head *), this tended to leave option->value.number as zero, thus messing up OPT_INT and OPT_BOOL at least. OPT_LONG however tended to work right. This would be easy to fix with C99 designated initializers, but doc/hacking.txt says ELinks must be kept C89 compatible. Another solution would be to make register_options() read the value from option->value.tree (the first member), cast it back to the right type, and write it to the appropriate member; but that would still require somewhat dubious conversions between integers, data pointers, and function pointers. So here's a rather more invasive solution. Add struct option_init, which is somewhat similar to struct option but has non-overlapping members for different types of values, to ensure nothing is lost in compile-time conversions. Move unsigned char *path from struct option_info to struct option_init, and replace struct option_info with a union that contains struct option_init and struct option. Now, this union can be initialized with no portability problems, and register_options() then moves the values from struct option_init to their final places in struct option. In my x86 ELinks build with plenty of options configured in, this change bloated the text section by 340 bytes but compressed the data section by 2784 bytes, presumably because union option_info is a pointer smaller than struct option_info was. (cherry picked from elinks-0.12 commit e5f6592ee20780a61f70feeb1f9e17631b9c5835) Conflicts: src/protocol/fsp/fsp.c: All options had been removed in 0.13.GIT. src/protocol/smb/smb2.c: Ditto.
2009-08-15 15:39:07 -04:00
static union option_info config_options_info[] = {
Here is a framework that detects cases where a PO file assigns the same accelerator key to multiple buttons in a dialog box or to multiple items in a menu. ELinks already has some support for this but it requires the translator to run ELinks and manually scan through all menus and dialogs. The attached changes make it possible to quickly detect and list any conflicts, including ones that can only occur on operating systems or configurations that the translator is not currently using. The changes have no immediate effect on the elinks executable or the MO files. PO files become larger, however. The scheme works like this: - Like before, accelerator keys in translatable strings are tagged with the tilde (~) character. - Whenever a C source file defines an accelerator key, it must assign one or more named "contexts" to it. The translations in the PO files inherit these contexts. If multiple strings use the same accelerator (case insensitive) in the same context, that's a conflict and can be detected automatically. - The contexts are defined with "gettext_accelerator_context" comments in source files. These comments delimit regions where all translatable strings containing tildes are given the same contexts. There must be one special comment at the top of the region; it lists the contexts assigned to that region. The region automatically ends at the end of the function (found with regexp /^\}/), but it can also be closed explicitly with another special comment. The comments are formatted like this: /* [gettext_accelerator_context(foo, bar, baz)] begins a region that uses the contexts "foo", "bar", and "baz". The comma is the delimiter; whitespace is optional. [gettext_accelerator_context()] ends the region. */ The scripts don't currently check whether this syntax occurs inside or outside comments. - The names of contexts consist of C identifiers delimited with periods. I typically used the name of a function that sets up a dialog, or the name of an array where the items of a menu are listed. There is a special feature for static functions: if the name begins with a period, then the period will be replaced with the name of the source file and a colon. - If a menu is programmatically generated from multiple parts, of which some are never used together, so that it is safe to use the same accelerators in them, then it is necessary to define multiple contexts for the same menu. link_menu() in src/viewer/text/link.c is the most complex example of this. - During make update-po: - A Perl script (po/gather-accelerator-contexts.pl) reads po/elinks.pot, scans the source files listed in it for "gettext_accelerator_context" comments, and rewrites po/elinks.pot with "accelerator_context" comments that indicate the contexts of each msgid: the union of all contexts of all of its uses in the source files. It also removes any "gettext_accelerator_context" comments that xgettext --add-comments has copied to elinks.pot. - If po/gather-accelerator-contexts.pl does not find any contexts for some use of an msgid that seems to contain an accelerator (because it contains a tilde), it warns. If the tilde refers to e.g. "~/.elinks" and does not actually mark an accelerator, the warning can be silenced by specifying the special context "IGNORE", which the script otherwise ignores. - msgmerge copies the "accelerator_context" comments from po/elinks.pot to po/*.po. Translators do not edit those comments. - During make check-po: - Another Perl script (po/check-accelerator-contexts.pl) reads po/*.po and keeps track of which accelerators have been bound in each context. It warns about any conflicts it finds. This script does not access the C source files; thus it does not matter if the line numbers in "#:" lines are out of date. This implementation is not perfect and I am not proposing to add it to the main source tree at this time. Specifically: - It introduces compile-time dependencies on Perl and Locale::PO. There should be a configure-time or compile-time check so that the new features are skipped if the prerequisites are missing. - When the scripts include msgstr strings in warnings, they should transcode them from the charset of the PO file to the one specified by the user's locale. - It is not adequately documented (well, except perhaps here). - po/check-accelerator-contexts.pl reports the same conflict multiple times if it occurs in multiple contexts. - The warning messages should include line numbers, so that users of Emacs could conveniently edit the conflicting part of the PO file. This is not feasible with the current version of Locale::PO. - Locale::PO does not understand #~ lines and spews warnings about them. There is an ugly hack to hide these warnings. - Jonas Fonseca suggested the script could propose accelerators that are still available. This has not been implemented. There are three files attached: - po/gather-accelerator-contexts.pl: Augments elinks.pot with context information. - po/check-accelerator-contexts.pl: Checks conflicts. - accelerator-contexts.diff: Makes po/Makefile run the scripts, and adds special comments to source files.
2005-12-04 18:38:29 -05:00
/* [gettext_accelerator_context(IGNORE)] */
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("", N_("Configuration system"),
"config", 0,
N_("Configuration handling options.")),
INIT_OPT_INT("config", N_("Comments"),
"comments", 0, 0, 3, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Amount of comments automatically written to the config "
"file:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 is no comments are written\n"
"1 is only the \"blurb\" (name+type) is written\n"
"2 is only the description is written\n"
"3 is full comments are written")),
INIT_OPT_INT("config", N_("Indentation"),
"indentation", 0, 0, 16, 2,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Shift width of one indentation level in the configuration "
"file. Zero means that no indentation is performed at all "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"when saving the configuration.")),
INIT_OPT_INT("config", N_("Saving style"),
"saving_style", 0, 0, 3, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Determines what happens when you tell ELinks to save "
"options:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 is only values of current options are altered\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"1 is values of current options are altered and missing\n"
" options are added at the end of the file\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"2 is the configuration file is rewritten from scratch\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"3 is values of current options are altered and missing\n"
" options CHANGED during this ELinks session are added at\n"
" the end of the file")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("config", N_("Comments localization"),
"i18n", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("If set to 1, comments in the configuration file will be "
"translated to the language used by UI. Note that if you have "
"different language set in different terminals, the language "
"used in the configuration file MAY be the same as on the "
"terminal where you saved the file, but it should be "
"generally considered unpredictable.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("config", N_("Saving style warnings"),
"saving_style_w", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("This is internal option used when displaying a warning "
"about obsolete config.saving_style. You shouldn't touch "
"it.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("config", N_("Show template"),
"show_template", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Show template options in autocreated trees in the options "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"manager and save them to the configuration file.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("Connections"),
"connection", OPT_SORT,
N_("Connection options.")),
INIT_OPT_BOOL("connection", N_("Asynchronous DNS"),
"async_dns", 0, 1,
N_("Whether to use asynchronous DNS resolving.")),
INIT_OPT_INT("connection", N_("Maximum connections"),
"max_connections", 0, 1, 16, 10,
N_("Maximum number of concurrent connections.")),
INIT_OPT_INT("connection", N_("Maximum connections per host"),
"max_connections_to_host", 0, 1, 8, 2,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Maximum number of concurrent connections to a given "
"host.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("connection", N_("Connection retries"),
"retries", 0, 0, 16, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of tries to establish a connection. "
"Zero means try forever.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("connection", N_("Receive timeout"),
"receive_timeout", 0, 1, 1800, 120,
N_("Receive timeout (in seconds).")),
#ifdef CONFIG_IPV6
INIT_OPT_BOOL("connection", N_("Try IPv4 when connecting"),
"try_ipv4", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to try to connect to a host over IPv4. "
"Note that if connection.try_ipv6 is enabled too, "
"it takes precedence. And better do not touch this "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"at all unless you are sure what are you doing.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
"Note that you can also force a given protocol "
"to be used on a per-connection basis by using a URL "
Change elinks.or.cz to elinks.cz and one i.e. to e.g. in option docs. Some other instances of elinks.or.cz still remain in the tree.
2006-09-02 10:50:53 -04:00
"in the style of e.g. http4://elinks.cz/.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#else
INIT_OPT_BOOL("connection", N_("Try IPv4 when connecting"),
"try_ipv4", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to try to connect to a host over IPv4. "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"Do not touch this option.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
"Note that you can also force a given protocol "
"to be used on a per-connection basis by using a URL "
Change elinks.or.cz to elinks.cz and one i.e. to e.g. in option docs. Some other instances of elinks.or.cz still remain in the tree.
2006-09-02 10:50:53 -04:00
"in the style of e.g. http4://elinks.cz/.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#endif
#ifdef CONFIG_IPV6
INIT_OPT_BOOL("connection", N_("Try IPv6 when connecting"),
"try_ipv6", 0, 1,
N_("Whether to try to connect to a host over IPv6.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
"Note that you can also force a given protocol "
"to be used on a per-connection basis by using a URL "
Change elinks.or.cz to elinks.cz and one i.e. to e.g. in option docs. Some other instances of elinks.or.cz still remain in the tree.
2006-09-02 10:50:53 -04:00
"in the style of e.g. http6://elinks.cz/.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#endif
INIT_OPT_INT("connection", N_("Timeout for non-restartable connections"),
"unrestartable_receive_timeout", 0, 1, 1800, 600,
N_("Timeout for non-restartable connections (in seconds).")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("Document"),
"document", OPT_SORT,
N_("Document options.")),
INIT_OPT_TREE("document", N_("Browsing"),
"browse", 0,
N_("Document browsing options (mainly interactivity).")),
INIT_OPT_TREE("document.browse", N_("Access keys"),
"accesskey", 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Options for handling of link access keys. "
"An HTML document can use the ACCESSKEY attribute to assign "
"an access key to an element. When an access key is pressed, "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"the corresponding element will be given focus.")),
INIT_OPT_BOOL("document.browse.accesskey", N_("Automatic links following"),
"auto_follow", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Automatically follow a link or submit a form if "
"appropriate accesskey is pressed - this is the standard "
"behaviour, but it's considered dangerous.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.accesskey", N_("Display access key in link info"),
"display", 0, 0,
N_("Display access key in link info.")),
INIT_OPT_INT("document.browse.accesskey", N_("Accesskey priority"),
"priority", 0, 0, 2, 0,
N_("Priority of 'accesskey' HTML attribute:\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"0 is first try all normal bindings; if it fails,\n"
" check accesskey\n"
"1 is first try only frame bindings; if it fails,\n"
" check accesskey\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"2 is first check accesskey (this can be dangerous)")),
INIT_OPT_TREE("document.browse", N_("Forms"),
"forms", 0,
N_("Options for handling of the forms interaction.")),
INIT_OPT_BOOL("document.browse.forms", N_("Submit form automatically"),
"auto_submit", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Automagically submit a form when enter is pressed with a "
"text field selected.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.forms", N_("Confirm submission"),
"confirm_submit", 0, 1,
N_("Ask for confirmation when submitting a form.")),
INIT_OPT_INT("document.browse.forms", N_("Default form input size"),
"input_size", 0, 3, 300, HTML_DEFAULT_INPUT_SIZE,
N_("Default form input size if none is specified.")),
INIT_OPT_BOOL("document.browse.forms", N_("Insert mode"),
"insert_mode", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("The setting for this option affects how key presses are "
"handled when one selects a text-input form-field. When "
"enabled, one must explicitly 'enter' a selected text-field "
"to edit it; this prevents text fields from capturing key "
"presses, such as presses of a scroll key, when it is "
"inadvertently selected. When disabled, key presses are "
"always inserted into a selected text field.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_STRING("document.browse.forms", N_("External editor"),
"editor", 0, "",
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Path to the executable that ELinks should launch when the "
"user requests to edit a textarea with an external editor.\n"
"\n"
"If this is blank, ELinks will use the value of the "
"environmental variable $EDITOR. If $EDITOR is empty or not "
"set, ELinks will then default to \"vi\".")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Images"),
"images", 0,
N_("Options for handling of images.")),
INIT_OPT_INT("document.browse.images", N_("Display style for image tags"),
"display_style", 0, 0, 3, 2,
N_("Display style for image tags when displayed:\n"
"0 means always display IMG\n"
"1 means always display filename\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"2 means display alt/title attribute if possible,\n"
" IMG if not\n"
"3 means display alt/title attribute if possible,\n"
" filename if not")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.images", N_("Maximum length for image filename"),
"filename_maxlen", 0, 0, 500, 0,
N_("Maximum length of image filename when displayed:\n"
"0 means always display full filename\n"
"1-500 means display filename with this maximal length;\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
" if it is longer, the middle is substituted by\n"
" an asterisk")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Compatibility aliases. Added: 2004-12-15, 0.10pre3.CVS. It was
* replaced by display_style and filename_maxlen options combination. */
INIT_OPT_ALIAS("document.browse.images", "file_tags", 0,
"document.browse.images.filename_maxlen"),
INIT_OPT_INT("document.browse.images", N_("Image links tagging"),
"image_link_tagging", 0, 0, 2, 1,
N_("When to enclose image links:\n"
"0 means never\n"
"1 means never if alt or title are provided (old behavior)\n"
"2 means always")),
INIT_OPT_STRING("document.browse.images", N_("Image link prefix"),
"image_link_prefix", 0, "[",
N_("Prefix string to use to mark image links.")),
INIT_OPT_STRING("document.browse.images", N_("Image link suffix"),
"image_link_suffix", 0, "]",
N_("Suffix string to use to mark image links.")),
INIT_OPT_INT("document.browse.images", N_("Maximum length for image label"),
"label_maxlen", 0, 0, 500, 0,
N_("Maximum length of image label (alt/title):\n"
"0 means always display full label\n"
"1-500 means display label with this maximal length;\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
" if it is longer, the middle is substituted by\n"
" an asterisk")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.images", N_("Display links to images w/o alt"),
"show_as_links", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Display links to images without an alt attribute. If this "
"option is off, these images are completely invisible.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.images", N_("Display links to images"),
"show_any_as_links", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Display links to any images in the document, regardless "
"of them having an alt attribute or not. If this option is "
"off, the alt attribute contents is shown, but as normal "
"text, not selectable as a link.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Links"),
"links", 0,
N_("Options for handling of links to other documents.")),
INIT_OPT_TREE("document.browse.links", N_("Active link"),
"active_link", 0,
N_("Options for the active link.")),
INIT_OPT_TREE("document.browse.links.active_link", N_("Colors"),
"colors", 0,
N_("Active link colors.")),
INIT_OPT_COLOR("document.browse.links.active_link.colors", N_("Background color"),
"background", 0, "#0000ff",
N_("Default background color.")),
INIT_OPT_COLOR("document.browse.links.active_link.colors", N_("Text color"),
"text", 0, "black",
N_("Default text color.")),
Provide different color for text areas in insert mode. The color is controlled by document.browse.links.active_link.insert_mode_colors.background document.browse.links.active_link.insert_mode_colors.text Also avoid overloading local variable "i" in get_current_link().
2009-05-01 15:39:30 -04:00
INIT_OPT_TREE("document.browse.links.active_link", N_("Insert mode colors"),
"insert_mode_colors", 0,
N_("Insert mode colors.")),
INIT_OPT_COLOR("document.browse.links.active_link.insert_mode_colors", N_("Background color for text field in insert mode"),
"background", 0, "#0000ff",
N_("Background color for text field in insert mode")),
INIT_OPT_COLOR("document.browse.links.active_link.insert_mode_colors", N_("Text color for text field in insert mode"),
"text", 0, "black",
N_("Text color for text field in insert mode.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.links.active_link", N_("Enable color"),
"enable_color", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Enable use of the active link background and text color "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"settings instead of the link colors from the document.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Bold"),
"bold", 0, 0,
N_("Make the active link text bold.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Invert colors"),
"invert", 0, 1,
N_("Invert the fore- and background color so the link "
"stands out.")),
INIT_OPT_BOOL("document.browse.links.active_link", N_("Underline"),
"underline", 0, 0,
N_("Underline the active link.")),
INIT_OPT_BOOL("document.browse.links", N_("Directory highlighting"),
"color_dirs", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Highlight links to directories in FTP and local directory "
"listing.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.links", N_("Number links"),
"numbering", 0, 0,
N_("Display numbers next to the links.")),
INIT_OPT_INT("document.browse.links", N_("Handling of target=_blank"),
"target_blank", 0, 0, 3, 0,
N_("Define how to handle links having target=_blank set:\n"
"0 means open link in current tab\n"
"1 means open link in new tab in foreground\n"
"2 means open link in new tab in background\n"
"3 means open link in new window")),
/* Compatibility aliases. Added: 2004-01-07, 0.9.0.CVS. */
INIT_OPT_ALIAS("document.browse.links", "typeahead_wraparound", 0,
"document.browse.search.wraparound"),
INIT_OPT_ALIAS("document.browse.links", "typeahead_error", 0,
"document.browse.search.show_not_found"),
INIT_OPT_BOOL("document.browse.links", N_("Use tabindex"),
"use_tabindex", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to navigate links using tabindex specified "
"ordering. The TABINDEX attribute in HTML elements specifies "
"the order in which links should receive focus when using the "
"keyboard to navigate the document.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Transfer changes for ascii link labeling
2016-01-31 04:23:08 -05:00
INIT_OPT_STRING("document.browse.links", N_("Specify link label key"),
"label_key", 0, "0123456789",
Multiplication instead of pow calls and minor style changes.
2016-01-31 06:38:18 -05:00
N_("Default is 0123456789, which is standard numeric labeling. "
"Ascii based strings like gfdsahjkl;trewqyuiopvcxznm can also "
Transfer changes for ascii link labeling
2016-01-31 04:23:08 -05:00
"be used.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.links", N_("Missing fragment reporting"),
"missing_fragment", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Open a message box when document has no tag with given "
"id.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.links", N_("Number keys select links"),
"number_keys_select_link", 0, 0, 2, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number keys select links rather than specify command "
"prefixes. This is a tristate:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 means never\n"
"1 means if document.browse.links.numbering = 1\n"
"2 means always")),
INIT_OPT_BOOL("document.browse.links", N_("Warn about maliciously crafted URIs"),
"warn_malicious", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("When following a link the user ID part of the URI is "
"checked and if a maliciously crafted URI is detected a "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"warning dialog will ask before following the link.")),
/* TODO - this is somehow implemented by ff, but disabled
* for now as it doesn't work. */
INIT_OPT_BOOL("document.browse.links", N_("Wrap-around links cycling"),
"wraparound", /* 0 */ 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("When pressing 'down' on the last link, jump to the first "
"one, and vice versa.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Scrolling"),
"scrolling", OPT_SORT,
N_("Scrolling options.")),
INIT_OPT_INT("document.browse.scrolling", N_("Horizontal step"),
"horizontal_step", 0, 1, 9999, 8,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of columns to scroll when a key bound to "
"scroll-left or scroll-right is pressed and no prefix was "
"given.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.scrolling", N_("Extended horizontal scrolling"),
"horizontal_extended", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to allow horizontal scrolling when the document "
"does not extend off the screen. Useful for copy/paste "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"operations.")),
INIT_OPT_INT("document.browse.scrolling", N_("Margin"),
"margin", 0, 0, 20, 3,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Size of the virtual margin - when you click inside of "
"that margin, document scrolls in that direction.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.scrolling", N_("Vertical step"),
"vertical_step", 0, 1, 9999, 2,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of lines to scroll when a key bound to scroll-up "
"or scroll-down is pressed and no prefix was given.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Add document.browse.scrolling.vertical_overlap Add an option to specify the number of overlapping lines when scrolling page by page (0 by default because this is ELinks' current behaviour). Signed-off-by: Fabienne Ducroquet <fabiduc@gmail.com>
2010-08-14 15:24:21 -04:00
INIT_OPT_INT("document.browse.scrolling", N_("Vertical overlap"),
"vertical_overlap", 0, 0, 10, 0,
N_("Number of overlapping lines between the new page displayed "
"and the previous one when scrolling one page up or down.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.browse", N_("Searching"),
"search", 0,
N_("Options for searching.")),
INIT_OPT_BOOL("document.browse.search", N_("Case sensitivity"),
"case", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether the search should match the document text while "
"maintaining case sensitivity.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
TRE: Check for 32-bit wchar_t at configure time This check used to be in src/elinks.h. Move it to configure.in so that (1) the result can be logged and (2) ELinks won't even link with TRE if wchar_t prevents its use. Also, rename HAVE_TRE_REGEX_H to CONFIG_TRE, to reflect that it is not always defined if the header exists.
2009-05-21 10:22:12 -04:00
#ifdef CONFIG_TRE
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.search", N_("Regular expressions"),
"regex", 0, 0, 2, 0,
N_("Enable searching with regular expressions:\n"
"0 for plain text searching\n"
"1 for basic regular expression searches\n"
"2 for extended regular expression searches")),
#endif
INIT_OPT_BOOL("document.browse.search", N_("Show search hit top or bottom dialogs"),
"show_hit_top_bottom", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to show a dialog when the search hits the top or "
"bottom of the document.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse.search", N_("Wraparound"),
"wraparound", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Wrap around when searching. Currently only used for "
"typeahead.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse.search", N_("Show not found"),
"show_not_found", 0, 0, 2, 2,
N_("How to inform the user when nothing is matched:\n"
"0 means do nothing\n"
"1 means beep the terminal\n"
"2 means pop up message box")),
INIT_OPT_INT("document.browse.search", N_("Typeahead searching"),
"typeahead", 0, 0, 2, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Start typeahead searching when an unbound key is pressed "
"without any modifiers. Note that most keys have default "
"bindings, so this feature will not be useful unless you "
"unbind them.\n"
"\n"
"0 disables this feature; typeahead searching will only be\n"
" used when you press a key bound to search-typeahead or\n"
" similar\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"1 automatically starts typeahead searching thru link text\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"2 automatically starts typeahead searching thru all document\n"
" text")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse", N_("Horizontal text margin"),
Allow larger document.browse.margin_width
2009-05-01 15:39:30 -04:00
"margin_width", 0, 0, 100, 3,
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
N_("Horizontal text margin.")),
Add preferred_document_width option. Option document.browse.preferred_document_width controls the width of the document, so that documents are rendered with narrower width than screen width. Makes it easier to read paragraphs. Patch originally from Shalon Wood <dstar@pele.cx>, see bug #1063. Instead of using max_document_width as the hard limit to the document width, it uses a soft limit, where if the document does not fit (due to tables, etc.), then larger width is used. This reduces the need for horizontal scrolling for wide documents. Also added toggle-document-width action to toggle between preferred width and full screen width. This is bound to 'M' by default. Initial toggle status is determined by document.browse.use_preferred_document_width option. During dumps, document.dump.width option is still used. Perhaps we should consolidate document.dump.width option with document.browse.preferred_document_width ?
2009-05-11 13:20:48 -04:00
INIT_OPT_INT("document.browse", N_("Preferred document width"),
"preferred_document_width", 0, 0, 9999, 80,
N_("Try to fit the document within this width. If set to zero,"
"use screen width.")),
INIT_OPT_BOOL("document.browse", N_("Whether to use preferred document width"),
"use_preferred_document_width", 0, 1,
N_("Whether to use preferred document width. If set to zero,\n"
"use screen width. If set to one, use preferred_document_width.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse", N_("Document meta refresh"),
"refresh", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Automatically follow document-specified refresh "
"directives ('<meta> refresh' tags). Web-page authors use "
"these to instruct the browser to reload a document at a "
"given interval or to load another page. Regardless of the "
"value the refresh URI is accessible as a link.\n"
"\n"
"Use the document.browse.minimum_refresh_time to control the "
"minimum number of seconds a refresh will wait.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("document.browse", N_("Document meta refresh minimum time"),
"minimum_refresh_time", 0, 0, INT_MAX, 1000,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("The minimum number of milliseconds that should pass "
"before refreshing. If set to zero the document refresh time "
"is used unchanged. It can fix going back in history for some "
"sites that use refreshing with zero values.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Introduced the document.browse.show_refresh_link option. Whether to show Refresh: link line. Default 1.
2015-01-02 08:53:18 -05:00
INIT_OPT_BOOL("document.browse", N_("Show meta refresh link"),
"show_refresh_link", 0, 1,
N_("Whether to show meta refresh link.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.browse", N_("Tables navigation order"),
"table_move_order", 0, 0,
N_("Move by columns in table, instead of rows.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("document", N_("Cache"),
"cache", OPT_SORT,
N_("Cache options.")),
INIT_OPT_BOOL("document.cache", N_("Cache information about redirects"),
"cache_redirects", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Cache even redirects sent by server (usually thru HTTP by "
"a 302 HTTP code and a Location header). This was the "
"original behaviour for quite some time, but it causes "
"problems in a situation very common to various web login "
"systems - frequently, when accessing a certain location, "
"they will redirect you to a login page if they don't receive "
"an auth cookie, the login page then gives you the cookie and "
"redirects you back to the original page, but there you have "
"already cached redirect back to the login page! If this "
"option has value of 0, this malfunction is fixed, but "
"occasionally you may get superfluous (depends on how you "
"take it ;-) requests to the server. If this option has value "
"of 1, experienced users can still workaround it by clever "
"combination of usage of reload, jumping around in session "
"history and hitting ctrl+enter.\n"
"\n"
"Note that this option is checked when retrieving the "
"information from cache, not when saving it to cache - thus "
"if you enable it, even previous redirects will be taken from "
"cache instead of asking the server.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.cache", N_("Ignore cache-control info from server"),
"ignore_cache_control", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Ignore Cache-Control and Pragma server headers. "
"When set, the document is cached even with 'Cache-Control: "
"no-cache'.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.cache", N_("Formatted documents"),
"format", 0,
N_("Format cache options.")),
INIT_OPT_INT("document.cache.format", N_("Number"),
"size", 0, 0, 256, 5,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Number of cached formatted pages. Do not get too "
"generous here, 'formatted' means that all the accompanying "
"structures are kept in memory so that you get the cached "
"document immediatelly, but these structures may take a lot "
"- 2x the size of the HTML source is probably not unusual, "
"but it can be even more if the document consists of a lot "
"of short lines (padded right, if possible) and links and "
"not much other markup. So if you set this to 256 and then "
"you don't like your ELinks eating 90M, don't come "
"complaining to us. ;-)\n"
"\n"
"Also note that the format cache itself is not counted to "
"the memory cache size, but the HTML source of the formatted "
"documents is always cached, even if it is over the memory "
"cache size threshold. (Then of course no other documents "
"can be cached.)")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Support for document.cache.interval (set it to -1) and rename it ...to document.cache.revalidation_interval. Moreover, -1 is the default now.
2006-11-03 13:56:55 -05:00
/* FIXME: Write more. */
Rewrite the description for document.cache.revalidation_interval again
2006-11-03 21:23:22 -05:00
INIT_OPT_INT("document.cache", N_("Revalidation interval"),
Fix wrongly placed -1 ;-)
2006-11-03 14:19:43 -05:00
"revalidation_interval", 0, -1, 86400, -1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Period in seconds that a cache entry is considered to be "
"up-to-date. When a document is loaded and this interval has "
"elapsed since the document was initially loaded or most "
"recently revalidated with the server, the server will be "
"checked in case there is a more up-to-date version of the "
"document.\n"
"\n"
document.cache.revalidation_interval: document that a value of -1 disables automatic revalidation
2007-02-28 15:22:40 -05:00
"A value of -1 disables automatic revalidation.")),
"If-Modified-Since" second approach. Added document.cache.interval option. When time elapsed since previous access to the document is less than interval then the document is taken from the cache. Otherwise the request with filled "If-Modified-Since" and/or "If-None-Match" header field is sent. By default interval is set to 10 minutes. This requires the correct time to be set on your machine.
2006-10-26 05:53:30 -04:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document.cache", N_("Memory cache"),
"memory", 0,
N_("Memory cache options.")),
INIT_OPT_LONG("document.cache.memory", N_("Size"),
"size", 0, 0, LONG_MAX, 1048576,
N_("Memory cache size (in bytes).")),
INIT_OPT_TREE("document", N_("Charset"),
"codepage", 0,
N_("Charset options.")),
INIT_OPT_CODEPAGE("document.codepage", N_("Default codepage"),
"assume", 0, "System",
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Default document codepage. 'System' stands for "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"a codepage determined by a selected locale.")),
INIT_OPT_BOOL("document.codepage", N_("Ignore charset info from server"),
"force_assumed", 0, 0,
N_("Ignore charset info sent by server.")),
INIT_OPT_TREE("document", N_("Default color settings"),
"colors", 0,
N_("Default document color settings.")),
INIT_OPT_COLOR("document.colors", N_("Text color"),
"text", 0, "#bfbfbf",
N_("Default text color.")),
INIT_OPT_COLOR("document.colors", N_("Background color"),
"background", 0, "#000000",
N_("Default background color.")),
INIT_OPT_COLOR("document.colors", N_("Link color"),
"link", 0, "#0000ff",
N_("Default link color.")),
INIT_OPT_COLOR("document.colors", N_("Visited-link color"),
"vlink", 0, "#ffff00",
N_("Default visited link color.")),
INIT_OPT_COLOR("document.colors", N_("Image-link color"),
"image", 0, "darkolivegreen",
N_("Default image link color.")),
INIT_OPT_COLOR("document.colors", N_("Bookmarked-link color"),
"bookmark", 0, "hotpink",
N_("Default bookmarked link color.")),
INIT_OPT_COLOR("document.colors", N_("Directory color"),
"dirs", 0, "#ffff00",
N_("Default directory color.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"See document.browse.links.color_dirs option.")),
/* Compatibility alias: added by jonas at 2005-05-31, 0.11.CVS. */
INIT_OPT_ALIAS("document.colors", "allow_dark_on_black", OPT_ALIAS_NEGATE,
"document.colors.increase_contrast"),
INIT_OPT_BOOL("document.colors", N_("Increase contrast"),
"increase_contrast", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Increase the contrast between the foreground and "
"background colors to ensure readability. For example it "
"disallows dark colors on a black background. Note, this "
"is different from ensuring the contrast with the "
"ensure_contrast option.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("document.colors", N_("Ensure contrast"),
"ensure_contrast", 0, 1,
Strings corrections from Malcolm Parsons Fix the spelling and grammar in various comments, variable names, comment descriptions, and documentation.
2008-01-26 23:09:18 -05:00
N_("Makes sure that the back- and foreground colors are never "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"equal.")),
/* If you change this please also change ACT_MAIN_DOCUMENT_COLORS action
* handling. */
INIT_OPT_INT("document.colors", N_("Use document-specified colors"),
"use_document_colors", 0, 0, 2, 2,
N_("Use colors specified in document:\n"
"0 is use always the default settings\n"
"1 is use document colors if available, except background\n"
"2 is use document colors, including background. This can\n"
" mostly look very impressive, but some sites will appear\n"
" really ugly. Note, that obviously if the background is\n"
" not black, it will break the behaviour of transparency.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("document", N_("Downloading"),
"download", 0,
N_("Options regarding files downloading and handling.")),
INIT_OPT_STRING("document.download", N_("Default download directory"),
"directory", 0, "./",
N_("Default download directory.")),
INIT_OPT_BOOL("document.download", N_("Set original time"),
"set_original_time", 0, 0,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Set the timestamp of each downloaded file to the "
"timestamp stored on the server.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Does automatic resuming make sense as an option? */
INIT_OPT_INT("document.download", N_("Prevent overwriting"),
"overwrite", 0, 0, 2, 2,
N_("Prevent overwriting the local files:\n"
"0 is files will silently be overwritten\n"
"1 is add a suffix .{number} (for example '.1') to the name\n"
"2 is ask the user")),
INIT_OPT_INT("document.download", N_("Notify download completion by bell"),
"notify_bell", 0, 0, 2, 0,
N_("Audio notification when download is completed:\n"
"0 is never\n"
"1 is when background notification is active\n"
"2 is always")),
INIT_OPT_TREE("document", N_("Dump output"),
"dump", 0,
N_("Dump output options.")),
INIT_OPT_CODEPAGE("document.dump", N_("Codepage"),
"codepage", 0, "System",
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Codepage used in dump output. 'System' stands for "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"a codepage determined by a selected locale.")),
1. If neither CONFIG_88_COLORS nor CONFIG_256_COLORS is defined, then dump_to_file_256 is defined in dump.c but not used. If configure --enable-debug was used, then gcc warns about the unused function, and the warning stops the build. 2. The description of document.dump.color_mode ends with a newline, provoking a runtime warning from check_description in src/config/options.c. 3. options.inc has preprocessor directives inside macro arguments. That is not portable C. xgettext (GNU gettext-tools) 0.14.3 is not smart enough to figure out the possible combinations, and copies an incorrect string to elinks.pot.
2006-03-13 13:06:02 -05:00
INIT_OPT_INT("document.dump", N_("Color mode"),
Bug 871, 752: Lock down enum color_mode and change option help to match. The numbering of document.dump.color_mode and terminal._template_.colors is now the same regardless of compile-time options, unlike in previous versions. Therefore this version of ELinks may interpret a configuration file differently from previous versions even if compiled with the same options. This is unfortunate but the alternatives (keeping the numbering dependent on configuration options; defining separate options that use the new numbering; starting the numbers from 10 or so and recognizing the previous ones only for compatibility) seem even worse.
2006-12-25 04:51:24 -05:00
"color_mode", 0, -1, COLOR_MODES - 1, -1,
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
/* The list of modes must be at the end of this string
* because AsciiDoc 7.1.2 does not support continuing
* an outer list entry after an inner list.
* TRANSLATORS: This restriction applies only to the
* "en" (English) translation. (See doc/Makefile.) */
N_("Color mode for dumps.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
"Some modes may have been disabled at compile time. "
"The Setup -> Terminal options dialog lists the modes "
"supported by this executable. If you select an "
"unsupported mode, ELinks uses 16 colors.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
"The color modes are:\n"
True color mode. See new konsole. TODO: dump
2006-08-19 17:39:40 -04:00
"-1 is standard dump mode\n"
"0 is mono mode\n"
"1 is 16 color mode\n"
"2 is 88 color mode\n"
"3 is 256 color mode\n"
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
"4 is true color mode")),
Bug 871, 752: Lock down enum color_mode and change option help to match. The numbering of document.dump.color_mode and terminal._template_.colors is now the same regardless of compile-time options, unlike in previous versions. Therefore this version of ELinks may interpret a configuration file differently from previous versions even if compiled with the same options. This is unfortunate but the alternatives (keeping the numbering dependent on configuration options; defining separate options that use the new numbering; starting the numbers from 10 or so and recognizing the previous ones only for compatibility) seem even worse.
2006-12-25 04:51:24 -05:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_STRING("document.dump", N_("Footer"),
"footer", 0, "",
N_("Footer string used in dumps. %u is substituted by URL.")),
INIT_OPT_STRING("document.dump", N_("Header"),
"header", 0, "",
N_("Header string used in dumps. %u is substituted by URL.")),
INIT_OPT_BOOL("document.dump", N_("Numbering"),
"numbering", 0, 1,
N_("Whether to print link numbers in dump output.")),
INIT_OPT_BOOL("document.dump", N_("References"),
"references", 0, 1,
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
N_("Whether to print references (URIs) of document links "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"in dump output.")),
INIT_OPT_STRING("document.dump", N_("Separator"),
"separator", 0, "\n\n",
N_("String which separates two dumps.")),
INIT_OPT_INT("document.dump", N_("Width"),
"width", 0, 1, 65536, DEFAULT_TERMINAL_WIDTH,
N_("Width of screen in characters when dumping documents.")),
INIT_OPT_TREE("document", N_("History"),
"history", OPT_SORT,
N_("History options.")),
INIT_OPT_BOOL("document.history", N_("Keep unhistory"),
"keep_unhistory", 0, 1,
N_("Keep unhistory (\"forward history\").")),
INIT_OPT_TREE("document", N_("HTML rendering"),
"html", 0,
N_("Options concerning the display of HTML pages.")),
INIT_OPT_BOOL("document.html", N_("Display frames"),
"display_frames", 0, 1,
N_("Display frames.")),
INIT_OPT_BOOL("document.html", N_("Display tables"),
"display_tables", 0, 1,
N_("Display tables.")),
INIT_OPT_BOOL("document.html", N_("Display subscripts"),
"display_subs", 0, 1,
N_("Display subscripts (as [thing]).")),
INIT_OPT_BOOL("document.html", N_("Display superscripts"),
"display_sups", 0, 1,
N_("Display superscripts (as ^thing).")),
Strings corrections from Malcolm Parsons Fix the spelling and grammar in various comments, variable names, comment descriptions, and documentation.
2008-01-26 23:09:18 -05:00
INIT_OPT_INT("document.html", N_("Rendering of HTML link element"),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"link_display", 0, 0, 5, 2,
N_("How to render <link> tags from the HTML header:\n"
"0 is nothing\n"
"1 is title\n"
"2 is name in addition\n"
"3 is hreflang in addition\n"
"4 is type in addition\n"
"5 is everything")),
INIT_OPT_BOOL("document.html", N_("Underline links"),
"underline_links", 0, 0,
N_("Underline links.")),
INIT_OPT_BOOL("document.html", N_("Wrap non breaking space"),
"wrap_nbsp", 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 do not honour non breaking space (the nbsp entity) "
"but allow to wrap the text. This can help keeping the width "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"of documents down so no horizontal scrolling is needed.")),
INIT_OPT_TREE("document", N_("Plain rendering"),
"plain", 0,
N_("Options concerning the display of plain text pages.")),
INIT_OPT_BOOL("document.plain", N_("Display URIs"),
"display_links", 0, 0,
N_("Display URIs in the document as links.")),
INIT_OPT_BOOL("document.plain", N_("Compress empty lines"),
"compress_empty_lines", 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_("Compress successive empty lines to only one in displayed "
"text.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("document", N_("URI passing"),
"uri_passing", OPT_SORT | OPT_AUTOCREATE,
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_("Rules for passing URIs to external commands. When one "
"rule is defined the link and tab menu will have a menu item "
"that makes it possible to pass the the link, frame or tab "
"URI to an external command. If several rules are defined the "
"link and tab menu will have a submenu of items for each "
"rule.\n"
"\n"
"Note, this is mostly useful for launching graphical viewers, "
"since there is no support for releasing the terminal while "
"the command runs. The action and submenus are also available "
"by binding keys to the frame-external-command, the "
"link-external-command, and the tab-external-command "
"actions.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_STRING("document.uri_passing", NULL,
"_template_", 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_("A rule for passing URI to an external command. "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"The format is:\n"
"%c in the string means the current URL\n"
Drop empty lines from option descriptions; doc/tools/help2doc don't like em
2006-01-03 09:15:36 -05:00
"%% in the string means '%'\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"Do _not_ put single- or double-quotes around %c.")),
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("Information files"),
"infofiles", OPT_SORT,
N_("Options for information files in ~/.elinks.")),
INIT_OPT_INT("infofiles", N_("Save interval"),
"save_interval", 0, 0, INT_MAX, 300,
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_("Interval at which to trigger information files in "
"~/.elinks to be saved to disk if they have changed "
"(seconds; 0 to disable)")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("infofiles", N_("Use secure file saving"),
"secure_save", 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_("First write data to unique temporary file, then rename "
"this file upon successfully finishing this. Note that this "
"relates only to config files, not downloaded files. "
"You may want to disable it if you are using some exotic "
"permissions for concerned files. Secure file saving is "
"automagically disabled if file is symlink.\n"
"\n"
"Warning: some systems (ie. OS/2, Win32) require that "
"destination file doesn't exist when rename(3) is called, "
"breaking atomicity, and reducing reliability of this "
"feature.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("infofiles", N_("Use fsync(3) with secure file saving"),
"secure_save_fsync", 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 using secure file saving, call fsync(3), if the OS "
"supports it, to force the OS immediately to write the "
"data to permanent storage. This is optional for those who "
"wish to avoid excessive disk I/O.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("Terminals"),
"terminal", OPT_AUTOCREATE,
N_("Terminal options.")),
INIT_OPT_TREE("terminal", NULL,
"_template_", 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 specific to this terminal type (according to "
"$TERM value).")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Document terminal._template_.m11_hack more and add comments.
2007-05-20 09:10:27 -04:00
/* TODO: Incorporate some of the following to the option text.
*
* When UTF-8 I/O is disabled:
* 0 (TERM_DUMB) outputs ASCII -+| characters.
* 1 (TERM_VT100) switches charsets with ^N and ^O.
* 2 (TERM_LINUX) outputs CP437 characters without switching
* charsets, so it works correctly only if the terminal uses
* CP437. Can also be made CP850 and CP852 compatible with
* the restrict_852 option.
* 3 (TERM_KOI8) outputs KOI8-R characters without switching
* charsets, so it works correctly only if the terminal uses
* KOI8-R and the user has selected either KOI8-R or ASCII
* in ELinks. It is also mostly compatible with KOI8-U.
* 4 (TERM_FREEBSD) outputs characters in the 0x80...0x9F
* range, which FreeBSD 4.0 (but not 5.0) treated as
* graphical.
Bug 1070: Support for fbterm. fbterm uses different 256 color sequences than xterm. color256_seqs are part of the driver info.
2009-03-27 14:44:46 -04:00
* 5 (TERM_FBTERM)
Document terminal._template_.m11_hack more and add comments.
2007-05-20 09:10:27 -04:00
*
* When UTF-8 I/O is enabled, ELinks outputs (almost) the same
* characters as above but encodes them in UTF-8 and does not
* switch charsets. So, it will work in any terminal that
* understands UTF-8 and has the characters in its font. */
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_INT("terminal._template_", N_("Type"),
Bug 1070: Support for fbterm. fbterm uses different 256 color sequences than xterm. color256_seqs are part of the driver info.
2009-03-27 14:44:46 -04:00
"type", 0, 0, 5, 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_("Terminal type; matters mostly only when drawing frames "
"and dialog box borders:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 is dumb terminal type, ASCII art\n"
"1 is VT100, simple but portable\n"
"2 is Linux, you get double frames and other goodies\n"
"3 is KOI-8\n"
Bug 1070: Support for fbterm. fbterm uses different 256 color sequences than xterm. color256_seqs are part of the driver info.
2009-03-27 14:44:46 -04:00
"4 is FreeBSD\n"
"5 is fbterm")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Bug 885: Proper charset support in xterm window title When ELinks runs in an X11 terminal emulator (e.g. xterm), or in GNU Screen, it tries to update the title of the window to match the title of the current document. To do this, ELinks sends an "OSC 1 ; Pt BEL" sequence to the terminal. Unfortunately, xterm expects the Pt string to be in the ISO-8859-1 charset, making it impossible to display e.g. Cyrillic characters. In xterm patch #210 (2006-03-12) however, there is a menu item and a resource that can make xterm take the Pt string in UTF-8 instead, allowing characters from all around the world. The downside is that ELinks apparently cannot ask xterm whether the setting is on or off; so add a terminal._template_.latin1_title option to ELinks and let the user edit that instead. Complete list of changes: - Add the terminal._template_.latin1_title option. But do not add that to the terminal options window because it's already rather crowded there. - In set_window_title(), take a new codepage argument. Use it to decode the title into Unicode characters, and remove only actual control characters. For example, CP437 has graphical characters in the 0x80...0x9F range, so don't remove those, even though ISO-8859-1 has control characters in the same range. Likewise, don't misinterpret single bytes of UTF-8 characters as control characters. - In set_window_title(), do not truncate the title to the width of the window. The font is likely to be different and proportional anyway. But do truncate before 1024 bytes, an xterm limit. - In struct itrm, add a title_codepage member to remember which charset the master said it was going to use in the terminal window title. Initialize title_codepage in handle_trm(), update it in dispatch_special() if the master sends the new request TERM_FN_TITLE_CODEPAGE, and use it in most set_window_title() calls; but not in the one that sets $TERM as the title, because that string was not received from the master and should consist of ASCII characters only. - In set_terminal_title(), convert the caller-provided title to ISO-8859-1 or UTF-8 if appropriate, and report the codepage to the slave with the new TERM_FN_TITLE_CODEPAGE request. The conversion can run out of memory, so return a success/error flag, rather than void. In display_window_title(), check this result and don't update caches on error. - Add a NEWS entry for all of this.
2008-12-28 20:09:53 -05:00
INIT_OPT_BOOL("terminal._template_", N_("Always encode xterm title in ISO-8859-1"),
"latin1_title", 0, 1,
N_("When updating the window title of xterm or a similar "
"terminal emulator, encode the title in ISO-8859-1 (Latin-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
"rather than in the charset used for other text in the "
"window. Cyrillic and other characters get replaced with "
"Latin ones. Xterm requires this unless you explicitly "
"enable UTF-8 titles in it.\n"
Bug 885: Proper charset support in xterm window title When ELinks runs in an X11 terminal emulator (e.g. xterm), or in GNU Screen, it tries to update the title of the window to match the title of the current document. To do this, ELinks sends an "OSC 1 ; Pt BEL" sequence to the terminal. Unfortunately, xterm expects the Pt string to be in the ISO-8859-1 charset, making it impossible to display e.g. Cyrillic characters. In xterm patch #210 (2006-03-12) however, there is a menu item and a resource that can make xterm take the Pt string in UTF-8 instead, allowing characters from all around the world. The downside is that ELinks apparently cannot ask xterm whether the setting is on or off; so add a terminal._template_.latin1_title option to ELinks and let the user edit that instead. Complete list of changes: - Add the terminal._template_.latin1_title option. But do not add that to the terminal options window because it's already rather crowded there. - In set_window_title(), take a new codepage argument. Use it to decode the title into Unicode characters, and remove only actual control characters. For example, CP437 has graphical characters in the 0x80...0x9F range, so don't remove those, even though ISO-8859-1 has control characters in the same range. Likewise, don't misinterpret single bytes of UTF-8 characters as control characters. - In set_window_title(), do not truncate the title to the width of the window. The font is likely to be different and proportional anyway. But do truncate before 1024 bytes, an xterm limit. - In struct itrm, add a title_codepage member to remember which charset the master said it was going to use in the terminal window title. Initialize title_codepage in handle_trm(), update it in dispatch_special() if the master sends the new request TERM_FN_TITLE_CODEPAGE, and use it in most set_window_title() calls; but not in the one that sets $TERM as the title, because that string was not received from the master and should consist of ASCII characters only. - In set_terminal_title(), convert the caller-provided title to ISO-8859-1 or UTF-8 if appropriate, and report the codepage to the slave with the new TERM_FN_TITLE_CODEPAGE request. The conversion can run out of memory, so return a success/error flag, rather than void. In display_window_title(), check this result and don't update caches on error. - Add a NEWS entry for all of this.
2008-12-28 20:09:53 -05:00
"\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 this option does not take effect immediately, try "
"switching to a different page so that ELinks notices "
"it needs to update the title.")),
Bug 885: Proper charset support in xterm window title When ELinks runs in an X11 terminal emulator (e.g. xterm), or in GNU Screen, it tries to update the title of the window to match the title of the current document. To do this, ELinks sends an "OSC 1 ; Pt BEL" sequence to the terminal. Unfortunately, xterm expects the Pt string to be in the ISO-8859-1 charset, making it impossible to display e.g. Cyrillic characters. In xterm patch #210 (2006-03-12) however, there is a menu item and a resource that can make xterm take the Pt string in UTF-8 instead, allowing characters from all around the world. The downside is that ELinks apparently cannot ask xterm whether the setting is on or off; so add a terminal._template_.latin1_title option to ELinks and let the user edit that instead. Complete list of changes: - Add the terminal._template_.latin1_title option. But do not add that to the terminal options window because it's already rather crowded there. - In set_window_title(), take a new codepage argument. Use it to decode the title into Unicode characters, and remove only actual control characters. For example, CP437 has graphical characters in the 0x80...0x9F range, so don't remove those, even though ISO-8859-1 has control characters in the same range. Likewise, don't misinterpret single bytes of UTF-8 characters as control characters. - In set_window_title(), do not truncate the title to the width of the window. The font is likely to be different and proportional anyway. But do truncate before 1024 bytes, an xterm limit. - In struct itrm, add a title_codepage member to remember which charset the master said it was going to use in the terminal window title. Initialize title_codepage in handle_trm(), update it in dispatch_special() if the master sends the new request TERM_FN_TITLE_CODEPAGE, and use it in most set_window_title() calls; but not in the one that sets $TERM as the title, because that string was not received from the master and should consist of ASCII characters only. - In set_terminal_title(), convert the caller-provided title to ISO-8859-1 or UTF-8 if appropriate, and report the codepage to the slave with the new TERM_FN_TITLE_CODEPAGE request. The conversion can run out of memory, so return a success/error flag, rather than void. In display_window_title(), check this result and don't update caches on error. - Add a NEWS entry for all of this.
2008-12-28 20:09:53 -05:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("terminal._template_", N_("Switch fonts for line drawing"),
"m11_hack", 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_("Switch fonts when drawing lines, enabling both local "
"characters and lines working at the same time. "
"ELinks uses this option only if UTF-8 I/O is disabled "
"and the terminal type is Linux or FreeBSD.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
terminal._template_.utf_8_io: Move the comment above the option and extend it. This lets xgettext attach the comment to a more appropriate msgid.
2006-12-22 19:49:44 -05:00
/* When CONFIG_UTF8 is defined, any code that reads the "utf_8_io"
* option should also check whether the "codepage" option is UTF-8,
* and if so, behave as if "utf_8_io" were 1. (When CONFIG_UTF8 is
* not defined, it should not be possible to set UTF-8 as "codepage";
* please report any such possibilities as bugs.) */
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("terminal._template_", N_("UTF-8 I/O"),
"utf_8_io", 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 I/O in UTF-8 for Unicode terminals. "
"Note that currently, only the subset of UTF-8 according to "
"terminal codepage is used. ELinks ignores this option "
"if the terminal codepage is UTF-8.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Bug 824: Disable combining characters unless --enable-combining. Label this as an experimental feature because it has so many bugs and it is not clear how they can be fixed.
2008-01-19 12:56:50 -05:00
#ifdef CONFIG_COMBINE
combined: Added the option "combine" to terminal and screen driver options. Note that, combining characters work only on XTerm with UTF-8 locale setings.
2008-01-03 06:57:24 -05:00
INIT_OPT_BOOL("terminal._template_", N_("Combining characters"),
"combine", 0, 0,
N_("Enable combining characters. It works only with "
"the xterm in UTF-8 mode.")),
Bug 824: Disable combining characters unless --enable-combining. Label this as an experimental feature because it has so many bugs and it is not clear how they can be fixed.
2008-01-19 12:56:50 -05:00
#endif
combined: Added the option "combine" to terminal and screen driver options. Note that, combining characters work only on XTerm with UTF-8 locale setings.
2008-01-03 06:57:24 -05:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("terminal._template_", N_("Restrict frames in cp850/852"),
"restrict_852", 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_("Restrict the characters used when drawing lines. "
"Makes sense only with linux terminals using the cp850/852 "
"character sets.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("terminal._template_", N_("Block cursor"),
"block_cursor", 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_("Move cursor to bottom right corner when done drawing. "
"This is particularly useful when we have a block cursor, "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"so that inversed text is displayed correctly.")),
INIT_OPT_INT("terminal._template_", N_("Color mode"),
"colors", 0, 0, COLOR_MODES - 1, 0,
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
/* The list of modes must be at the end of this string
* because AsciiDoc 7.1.2 does not support continuing
* an outer list entry after an inner list.
* TRANSLATORS: This restriction applies only to the
* "en" (English) translation. (See doc/Makefile.) */
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 color mode controls what colors are used and how they "
"are output to the terminal.\n"
"\n"
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
"Some modes may have been disabled at compile time. "
"The Setup -> Terminal options dialog lists the modes "
"supported by this executable. If you select an "
"unsupported mode, ELinks uses 16 colors.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
"The color modes are:\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"0 is mono mode, only 2 colors are used\n"
"1 is 16 color mode, uses the common ANSI colors\n"
Bug 871, 752: Lock down enum color_mode and change option help to match. The numbering of document.dump.color_mode and terminal._template_.colors is now the same regardless of compile-time options, unlike in previous versions. Therefore this version of ELinks may interpret a configuration file differently from previous versions even if compiled with the same options. This is unfortunate but the alternatives (keeping the numbering dependent on configuration options; defining separate options that use the new numbering; starting the numbers from 10 or so and recognizing the previous ones only for compatibility) seem even worse.
2006-12-25 04:51:24 -05:00
"2 is 88 color mode, uses XTerm RGB codes\n"
"3 is 256 color mode, uses XTerm RGB codes\n"
Bug 752: Rearrange the docstrings of color-mode options. In the elinks.conf.5 manual page, the text below the list of modes was getting included in the last list item. This appears to be a design error in AsciiDoc. Work around it by moving the text above the list.
2007-01-06 16:36:45 -05:00
"4 is true color mode, uses konsole RGB codes")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("terminal._template_", N_("Transparency"),
Turn terminal transparency off by default The problem is that if you run elinks in xterm with the default white background, it will be totally unreadable if transparency is turned on. We should default to usability in all common environments, eyecandy lovers can do the extra setup for their specific one. It also makes the description note that elinks still assumes the background is black.
2006-11-05 10:28:53 -05:00
"transparency", 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 we should not set the background to black. "
"This is particularly useful when we have a terminal "
"(typically in some windowing environment) with a background "
"image or a transparent background - it will be visible in "
"ELinks as well (but ELinks document color handling will "
"still assume the background is black so if you have a "
"bright background you might experience contrast problems). "
"Note that this option makes sense only when colors are "
"enabled.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Add support for ECMA-48 SGR italic Add 'Italic' checkbox to Terminal options dialog box. Enable italic text by default for rxvt-unicode (and also enable frames, 88-colour mode, and underline).
2009-01-01 14:59:57 -05:00
INIT_OPT_BOOL("terminal._template_", N_("Italic"),
"italic", 0, 0,
N_("If we should use italics.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("terminal._template_", N_("Underline"),
"underline", 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 we should use underline or enhance the color "
"instead.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_CODEPAGE("terminal._template_", N_("Codepage"),
"charset", 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 of charset used for displaying content on "
"terminal. 'System' stands for a codepage determined by "
"a selected locale.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Keep options in alphabetical order. */
INIT_OPT_TREE("", N_("User interface"),
"ui", OPT_SORT,
N_("User interface options.")),
INIT_OPT_TREE("ui", N_("Color settings"),
"colors", 0,
N_("Default user interface color settings.")),
/* ========================================================== */
/* ============= BORING PART (colors) START ================= */
/* ========================================================== */
/* XXX: All bfu colors needs to have both 'text' and 'background'
* options even if it is not used. get_bfu_color() depends
* on it. */
/* The colors and mono tree should be similar but with different default
* values of course so always use the macros below. */
#define DO_INIT_OPT_COLORS(subtree, capt, name, fg, bg, desc) \
INIT_OPT_TREE(subtree, capt, name, 0, desc), \
INIT_OPT_COLOR(subtree "." name, N_("Text color"), \
"text", 0, fg, N_("Default text color.")), \
INIT_OPT_COLOR(subtree "." name, N_("Background color"), \
"background", 0, bg, N_("Default background color."))
#define INIT_OPT_COLORS(subtree, capt, name, cfg, cbg, mfg, mbg, desc) \
DO_INIT_OPT_COLORS("ui.colors.color" subtree, capt, name, cfg, cbg, desc), \
DO_INIT_OPT_COLORS("ui.colors.mono" subtree, capt, name, mfg, mbg, desc)
#define INIT_OPT_COLOR_TREE(subtree, capt, name, desc) \
INIT_OPT_TREE("ui.colors.color" subtree, capt, name, 0, desc), \
INIT_OPT_TREE("ui.colors.mono" subtree, capt, name, 0, desc)
INIT_OPT_TREE("ui.colors", N_("Color terminals"),
"color", 0,
N_("Color settings for color terminal.")),
INIT_OPT_TREE("ui.colors", N_("Non-color terminals"),
"mono", 0,
N_("Color settings for non-color terminal.")),
/* FIXME: obsolete, how to alias them correctly ? --Zas */
INIT_OPT_COLOR_TREE("", N_("Main menu bar"),
"mainmenu",
N_("Main menu bar colors.")),
INIT_OPT_COLORS(".mainmenu", N_("Unselected main menu bar item"),
"normal", "black", "white", "black", "white",
N_("Unselected main menu bar item colors.")),
INIT_OPT_COLORS(".mainmenu", N_("Selected main menu bar item"),
"selected", "green", "black", "gray", "black",
N_("Selected main menu bar item colors.")),
INIT_OPT_COLOR_TREE(".mainmenu", N_("Hotkey"),
"hotkey",
N_("Main menu hotkey colors.")),
INIT_OPT_COLORS(".mainmenu.hotkey", N_("Unselected hotkey"),
"normal", "darkred", "white", "black", "white",
N_("Main menu unselected hotkey colors.")),
INIT_OPT_COLORS(".mainmenu.hotkey", N_("Selected hotkey"),
"selected", "darkred", "green", "black", "white",
N_("Main menu selected hotkey colors.")),
INIT_OPT_COLOR_TREE("", N_("Menu bar"),
"menu",
N_("Menu bar colors.")),
INIT_OPT_COLORS(".menu", N_("Unselected menu item"),
"normal", "black", "white", "black", "white",
N_("Unselected menu item colors.")),
INIT_OPT_COLORS(".menu", N_("Selected menu item"),
"selected", "black", "green", "gray", "black",
N_("Selected menu item colors.")),
INIT_OPT_COLORS(".menu", N_("Marked menu item"),
"marked", "red", "white", "gray", "white",
N_("Marked menu item colors.")),
INIT_OPT_COLOR_TREE(".menu", N_("Hotkey"),
"hotkey",
N_("Menu item hotkey colors.")),
INIT_OPT_COLORS(".menu.hotkey", N_("Unselected hotkey"),
"normal", "darkred", "white", "gray", "black",
N_("Menu item unselected hotkey colors.")),
INIT_OPT_COLORS(".menu.hotkey", N_("Selected hotkey"),
"selected", "darkred", "green", "gray", "black",
N_("Menu item selected hotkey colors.")),
INIT_OPT_COLORS(".menu", N_("Menu frame"),
"frame", "black", "white", "black", "white",
N_("Menu frame colors.")),
INIT_OPT_COLOR_TREE("", N_("Dialog"),
"dialog",
N_("Dialog colors.")),
/* Compatibility alias: added by jonas at 2003-10-18, 0.5pre7.CVS. */
INIT_OPT_ALIAS("ui.colors.color.dialog", "background", 0,
"ui.colors.color.dialog.generic.background"),
/* Compatibility alias: added by jonas at 2003-10-18, 0.5pre7.CVS. */
INIT_OPT_ALIAS("ui.colors.mono.dialog", "background", 0,
"ui.colors.mono.dialog.generic.background"),
INIT_OPT_COLORS(".dialog", N_("Generic"),
"generic", "black", "white", "black", "white",
N_("Generic dialog colors.")),
INIT_OPT_COLORS(".dialog", N_("Frame"),
"frame", "black", "white", "black", "white",
N_("Dialog frame colors.")),
INIT_OPT_COLORS(".dialog", N_("Scrollbar"),
"scrollbar", "black", "blue", "white", "black",
N_("Scrollbar colors.")),
INIT_OPT_COLORS(".dialog", N_("Selected scrollbar"),
"scrollbar-selected", "black", "green", "black", "white",
N_("Scrollbar selected colors.")),
INIT_OPT_COLORS(".dialog", N_("Title"),
"title", "darkred", "white", "gray", "black",
N_("Dialog title colors.")),
INIT_OPT_COLORS(".dialog", N_("Text"),
"text", "black", "white", "black", "white",
N_("Dialog text colors.")),
INIT_OPT_COLORS(".dialog", N_("Checkbox"),
"checkbox", "darkred", "white", "black", "white",
N_("Dialog checkbox colors.")),
INIT_OPT_COLORS(".dialog", N_("Selected checkbox"),
"checkbox-selected", "yellow", "green", "white", "black",
N_("Dialog selected checkbox colors.")),
INIT_OPT_COLORS(".dialog", N_("Checkbox label"),
"checkbox-label", "black", "white", "black", "white",
N_("Dialog checkbox label colors.")),
INIT_OPT_COLORS(".dialog", N_("Button"),
"button", "white", "blue", "black", "white",
N_("Dialog button colors.")),
INIT_OPT_COLORS(".dialog", N_("Selected button"),
"button-selected", "yellow", "green", "white", "black",
N_("Dialog selected button colors.")),
INIT_OPT_COLORS(".dialog", N_("Button shortcut"),
"button-shortcut", "yellow", "blue", "white", "black",
N_("Dialog button colors.")),
INIT_OPT_COLORS(".dialog", N_("Selected button shortcut"),
"button-shortcut-selected", "white", "blue", "black", "white",
N_("Dialog selected button colors.")),
INIT_OPT_COLORS(".dialog", N_("Text field"),
"field", "white", "blue", "gray", "black",
N_("Dialog text field colors.")),
INIT_OPT_COLORS(".dialog", N_("Text field text"),
"field-text", "yellow", "blue", "gray", "black",
N_("Dialog field text colors.")),
INIT_OPT_COLORS(".dialog", N_("Meter"),
"meter", "white", "blue", "gray", "black",
N_("Dialog meter colors.")),
INIT_OPT_COLORS(".dialog", N_("Shadow"),
"shadow", "black", "black", "black", "black",
N_("Dialog shadow colors (see ui.shadows option).")),
INIT_OPT_COLOR_TREE("", N_("Title bar"),
"title",
N_("Title bar colors.")),
INIT_OPT_COLORS(".title", N_("Generic title bar"),
"title-bar", "black", "white", "gray", "black",
N_("Generic title bar colors.")),
INIT_OPT_COLORS(".title", N_("Title bar text"),
"title-text", "black", "white", "gray", "black",
N_("Title bar text colors.")),
INIT_OPT_COLOR_TREE("", N_("Status bar"),
"status",
N_("Status bar colors.")),
Show IP of the document in the status bar. config options: ui.show_ip (0/1) default 0 status.showip-text - colors
2010-03-30 08:45:19 -04:00
INIT_OPT_COLORS(".status", N_("Status bar show ip"),
"showip-text", "black", "white", "black", "white",
N_("Status bar show ip text colors.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_COLORS(".status", N_("Generic status bar"),
"status-bar", "black", "white", "black", "white",
N_("Generic status bar colors.")),
Show IP of the document in the status bar. config options: ui.show_ip (0/1) default 0 status.showip-text - colors
2010-03-30 08:45:19 -04:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_COLORS(".status", N_("Status bar text"),
"status-text", "black", "white", "black", "white",
N_("Status bar text colors.")),
INIT_OPT_COLOR_TREE("", N_("Tabs bar"),
"tabs",
N_("Tabs bar colors.")),
INIT_OPT_COLORS(".tabs", N_("Unvisited tab"),
"unvisited", "darkblue", "white", "gray", "white",
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_("Tab colors for tabs that have not been "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"selected since they completed loading.")),
INIT_OPT_COLORS(".tabs", N_("Unselected tab"),
"normal", "black", "white", "black", "white",
N_("Unselected tab colors.")),
INIT_OPT_COLORS(".tabs", N_("Loading tab"),
"loading", "darkred", "white", "gray", "white",
N_("Tab colors for tabs that are loading in the background.")),
INIT_OPT_COLORS(".tabs", N_("Selected tab"),
"selected", "black", "green", "gray", "black",
N_("Selected tab colors.")),
INIT_OPT_COLORS(".tabs", N_("Tab separator"),
"separator", "brown", "white", "gray", "white",
N_("Tab separator colors.")),
INIT_OPT_COLORS("", N_("Searched strings"),
"searched", "black", "lime", "black", "white",
N_("Searched string highlight colors.")),
/* ========================================================== */
/* ============= BORING PART (colors) END =================== */
/* ========================================================== */
/* Keep options in alphabetical order. */
INIT_OPT_TREE("ui", N_("Dialog settings"),
"dialogs", 0,
N_("Dialogs-specific appearance and behaviour settings.")),
INIT_OPT_INT("ui.dialogs", N_("Minimal height of listbox widget"),
"listbox_min_height", 0, 1, 20, 10,
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_("Minimal height of the listbox widget (used e.g. for "
"bookmarks or global history).")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui.dialogs", N_("Drop shadows"),
"shadows", 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_("Make dialogs drop shadows (the shadows are solid, you "
"can adjust their color by ui.colors.*.dialog.shadow). "
"You may also want to eliminate the wide borders by "
"adjusting setup.h.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui.dialogs", N_("Underline menu hotkeys"),
"underline_hotkeys", 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 to underline hotkeys in menus to make them more "
"visible. Requires that underlining is enabled for the "
"terminal.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui.dialogs", N_("Underline button shortcuts"),
"underline_button_shortcuts", 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 to underline button shortcuts to make them more "
"visible. Requires that underlining is enabled for the "
"terminal.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("ui", N_("Timer options"),
"timer", 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_("Timed action after certain interval of user inactivity. "
"Someone can even find this useful, although you may not "
"believe that.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#ifdef CONFIG_LEDS
INIT_OPT_INT("ui.timer", N_("Enable"),
"enable", 0, 0, 2, 0,
N_("Whether to enable the timer or not:\n"
"0 is don't count down anything\n"
"1 is count down, but don't show the timer\n"
"2 is count down and show the timer near LEDs")),
#else
INIT_OPT_INT("ui.timer", N_("Enable"),
"enable", 0, 0, 2, 0,
N_("Whether to enable the timer or not:\n"
"0 is don't count down anything\n"
"1 is count down, but don't show the timer\n"
"2 is count down and show the timer near LEDs (DISABLED)")),
#endif
INIT_OPT_INT("ui.timer", N_("Duration"),
"duration", 0, 1, 86400, 86400,
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_("Inactivity timeout in seconds. The maximum of one day "
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"should be enough for just everyone (TM).")),
INIT_OPT_STRING("ui.timer", N_("Action"),
"action", 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_("Keybinding action to be triggered when timer reaches "
"zero.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("ui", N_("Window tabs"),
"tabs", 0,
N_("Window tabs settings.")),
INIT_OPT_INT("ui.tabs", N_("Display tabs bar"),
"show_bar", 0, 0, 2, 1,
N_("Show tabs bar on the screen:\n"
"0 means never\n"
"1 means only if two or more tabs are open\n"
"2 means always")),
Display optionally tabs bar at top like other browser do. TODO: input_line_layouter, ACT_MAIN_TAB_MENU
2006-03-04 04:24:37 -05:00
INIT_OPT_BOOL("ui.tabs", N_("Tab bar at top"),
"top", 0, 0,
N_("Whether display tab bar at top like other browsers do.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui.tabs", N_("Wrap-around tabs cycling"),
"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_("When moving right from the last tab, jump to the first "
"one, and vice versa.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui.tabs", N_("Confirm tab closing"),
"confirm_close", 0, 0,
N_("When closing a tab show confirmation dialog.")),
INIT_OPT_LANGUAGE("ui", N_("Language"),
"language", 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_("Language of user interface. 'System' means that the "
"language will be extracted from the environment "
"dynamically.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
Someone, sometime ago wanted always visible menu bar. This is attempt to handle it. I have no idea where to make initialisation call to activate_bfu_technology.
2006-03-03 13:01:15 -05:00
INIT_OPT_BOOL("ui", N_("Display menu bar always"),
"show_menu_bar_always", 0, 0,
N_("Always show menu bar on the screen.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui", N_("Display status bar"),
"show_status_bar", 0, 1,
N_("Show status bar on the screen.")),
INIT_OPT_BOOL("ui", N_("Display title bar"),
"show_title_bar", 0, 1,
N_("Show title bar on the screen.")),
INIT_OPT_BOOL("ui", N_("Display goto dialog in new tabs"),
"startup_goto_dialog", 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_("Pop up goto dialog in newly created tabs when there's "
"no homepage set. This means also showing goto dialog on "
"startup.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui", N_("Show a message box when file is saved successfully"),
"success_msgbox", 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 you pressed a [ Save ] button in some manager, "
"this option will make sure that a box confirming success "
"of the operation will pop up.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_TREE("ui", N_("Sessions"),
"sessions", OPT_SORT,
N_("Sessions settings.")),
Re-commit the rest of the changes which was reverted in the recent 'funny merge'
2005-10-17 17:20:53 -04:00
INIT_OPT_BOOL("ui.sessions", N_("Keep session active"),
"keep_session_active", 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_("Keep the session active even if the last terminal "
"exits.")),
Re-commit the rest of the changes which was reverted in the recent 'funny merge'
2005-10-17 17:20:53 -04:00
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
INIT_OPT_BOOL("ui.sessions", N_("Auto save session"),
"auto_save", 0, 0,
N_("Automatically save the session when quitting.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"This feature requires bookmark support.")),
INIT_OPT_BOOL("ui.sessions", N_("Auto restore session"),
"auto_restore", 0, 0,
N_("Automatically restore the session at start.\n"
Rewrap lines in option documentation. Documentation strings of most options used to contain a "\n" at the end of each source line. When the option manager displayed these strings, it treated each "\n" as a hard newline. On 80x24 terminals however, the option description window has only 60 columes available for the text (with the default setup.h), and the hard newlines were further apart, so the option manager wrapped the text a second time, resulting in rather ugly output where long lones are interleaved with short ones. This could also cause the text to take up too much vertical space and not fit in the window. Replace most of those hard newlines with spaces so that the option manager (or perhaps BFU) will take care of the wrapping. At the same time, rewrap the strings in source code so that the source lines are at most 79 columns wide. In some options though, there is a list of possible values and their meanings. In those lists, if the description of one value does not fit in one line, then continuation lines should be indented. The option manager and BFU are not currently able to do that. So, keep the hard newlines in those lists, but rewrap them to 60 columns so that they are less likely to require further wrapping at runtime.
2009-03-07 13:48:38 -05:00
"\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"This feature requires bookmark support.")),
INIT_OPT_STRING("ui.sessions", N_("Auto save and restore session folder name"),
"auto_save_foldername", 0, "Auto saved session",
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_("Name of the bookmarks folder used for auto saving and "
"restoring session. The name has to be unique. Any folders "
"with the same name will be deleted.\n"
"\n"
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
"This only makes sense with bookmark support.")),
INIT_OPT_STRING("ui.sessions", N_("Homepage URI"),
"homepage", 0, WWW_HOME_URL,
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 URI to load either at startup time when no URI was "
"given on the command line or when requested by the "
"goto-url-home action. Set to \"\" if the environment "
"variable WWW_HOME should be used as homepage URI instead.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
#ifdef HAVE_STRFTIME
INIT_OPT_STRING("ui", N_("Date format"),
"date_format", 0, "%b %e %H:%M",
N_("Date format to use in dialogs. See strftime(3).")),
#endif
INIT_OPT_BOOL("ui", N_("Set window title"),
"window_title", 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_("Set the window title when running in a windowing "
"environment in an xterm-like terminal. This way the "
"document's title is shown on the window titlebar.")),
Initial commit of the HEAD branch of the ELinks CVS repository, as of Thu Sep 15 15:57:07 CEST 2005. The previous history can be added to this by grafting.
2005-09-15 09:58:31 -04:00
/* Compatibility alias: added by pasky at 2004-07-22, 0.9.CVS. */
INIT_OPT_ALIAS("", "secure_file_saving", 0, "infofiles.secure_save"),
NULL_OPTION_INFO,
};
/* vim: set filetype=c : */
Copy Permalink