Getting ELinks up and running
Prev |  | Next

## Getting ELinks up and running

Installing ELinks should be pretty easy on most systems. Below is described the whole process of configuring the compilation, compiling and installing.

### Building and Installing ELinks

The quick guide for the impatient. Issue the following commands from the ELinks source directory:

    $ meson setup build
    $ meson compile -C build
    $ sudo meson install -C build

However you might consider to tweek a few compile time options before building ELinks. You might also want to take a look at what libraries and programs are required or recommended that you install.

### Requirements

To successfully install ELinks all that is required is meson (version 1.0.1 or later) and a C compiler.

### Recommended Libraries and Programs

To make use of many of ELinks features you will need to have some external libraries and utility programs installed on your system. It is recommended to have the following libraries and programs installed:

Dependency | Description
--- | ---
Lua, Guile, python3, perl or ruby | Makes it possible to write scripting plugins. See the Elinks - Lua interface for more info.
zlib 1.2.0.2 or later | For handling gzip or deflate compressed documents both locally and sent from server.
brotli | For brotli compressed documents.
bzip2 | Likewise, for bzip2 compressed documents.
xz utils | Likewise, for LZMA compressed documents.
zstd | For zstd compressed documents.
OpenSSL, GNU TLS, or nss_compat_ossl | For handling secure HTTP browsing and gemini.
libcurl | For SFTP, FTPes and as an alternative protocol "engine" for http and ftp.
libevent or libev | Alternative to the select an event loop library.
fsplib | For FSP protocol.
pkg-config | Needed for locating some libraries (at least GNU TLS, TRE, and SpiderMonkey).
GPM | General Purpose Mouse for mouse support.
expat | XML Parser Toolkit needed for XBEL support.
TRE | For regexp searching. Version 0.8.0 works.
libsmbclient | Library needed for smb:// protocol support.
rxvt-unicode | For terminal emulator which supports 88 colors.
xterm with 256 colors | Program atleast patch level 179 or rxvt program from version 2.7.9 for support of 256 colors. Newer PuTTY also has 256 color support.
libidn2 | For internationalized domain names.
SpiderMonkey | Mozilla's JavaScript engine for getting JavaScript/ECMAScript support in ELinks.
QuickJS | Alternative engine for JavaScript.
MuJS | Another ECMAScript engine.
libsqlite | For local storage in js.
libparserutils, libhubbub, libwapcaplet, libdom, libcss | Libraries required for js and CSS support.
See also notes on ECMAScript support. |

When compiling, you also need the header files for the libraries. Most OS distributors put a given library's headers in a package separate from the library itself; this package usually has `-dev` or similar appended to its name.

### Further reading

This installation guide is far from being complete. You are also advised to read the `README` and the `INSTALL` files distributed with ELinks for further up to date info on building and installing.

### Tips to obtain a very small static elinks binary

Tips to obtain a very small static elinks binary suitable for mini distributions

Remove config.cache (previous CC may be cached):

    $ rm config.cache

Use dietlibc (http://www.fefe.de/dietlibc/) or similar stuff (uClibc, …):

    $ export CC='diet -Os gcc'

Use compilers flags to optimize for size:

    $ export CFLAGS='-s -fno-inline -nostdinc -fomit-frame-pointer'

Note that if you don't use dietlibc, you definitively want to add `-Os` or `-O2` to `CFLAGS`; GCC 2.95 does not know `-Os`, and some say `-O2` gives smaller executables even for GCC 3.x.

### Tip

If you use these `CFLAGS` on Cygwin and you get unresolved symbols (`htons` and suite in particular), try removing `-fno-inline` parameter.

Disable some compile-time options:

    $ ./configure --disable-ipv6 --disable-backtrace --disable-nls \
      --enable-fastmem --without-zlib --without-bzlib --disable-xbel \
      --without-lua --without-gnutls --without-openssl --without-x \
      --enable-small --without-spidermonkey --without-gpm

You can disable bookmarks, globhist and more, too, if you want to.

### Other configure options that can reduce the size

- --disable-backtrace disables internal backtrace code.
- --disable-nls disables i18n support.
- --enable-fastmem disables internal `malloc()` debugging and use `alloca()` wherever possible.
- --enable-small forces to remove some text descriptions in options and keybind stuff (regain 30Kb).

Dependencies over external libs must be removed using the related configure options:

Option | Description
--- | ---
--without-zlib | removes libz dependency (compression)
--without-bzlib | removes libbz2 dependency (compression)
--disable-xbel | removes expat dependency (XBEL bookmarks support)
--without-lua | removes liblua dependency (Lua scripting)
--without-gnutls | removes libtls dependency (SSL support)
--without-openssl | removes libssl dependency (SSL support)
--without-x | removes libx11 dependency (restoring terminal title)
--without-spidermonkey | removes libjs dependency (JavaScript)
--without-gpm | removes libgpm dependency (mouse/console)

It seems GCC 2.95.x do not generate as small binaries as GCC 3.2.x with same flags.

You can use an executable compressor like UPX http://upx.sourceforge.net/.

Here are some results using gcc 2.95.3, dietlibc-0.23, and previous flags:

    me$ ls -l src/elinks
    -rwxr-xr-x   1 zas      users      495100 Oct 20 15:53 src/elinks
    me$ upx --best src/elinks
    me$ ls -l src/elinks
    -rwxr-xr-x   1 zas      users      217946 Oct 20 15:53 src/elinks

Whow ! Around 200kb :)

### Details about the `--enable-small` configure option effects:

- it disables long descriptions of options;
- it disables textual descriptions of keybinding options;
- it reduces size of some HTTP errors messages;
- it disables fastfind feature, reducing performance, but also reducing a lot memory usage, and a bit the executable size.

### ECMAScript support?!

Yes, there is some ECMAScript support in ELinks. There isn't anything we could call complete, but some bits could help with the most common ECMAScript usage cases - help you (and then us ;) get into your banking account, pass through those ignorant page redirects done by JavaScript code snippets and so.

ELinks does not have own ECMAScript parser and compiler; instead it reuses other people's work (this may eventually change, see the bottom of this file). First we aimed at the NJS engine, which is easy to install, small and compact; has nice naming scheme, horrible calling conventions and very lacking documentation; is not actively developed; and generally looks broken and extremely clumsy to work with. So we instead went the way of the SpiderMonkey (SM) engine (property of Mozilla), which is hard to install, bigger (mind you, it comes from Mozilla ;), has ugly naming scheme but nice calling conventions, acceptable documentation, is actively developed and ought to work.

#### Ok, so how to get the ECMAScript support working?

On Debian testing or unstable (SID), run the following:

    $ apt-get install libmozjs-128-dev

On Arch Linux, run the following:

    $ pacman -S js128

SpiderMonkey is disabled by default, enable it like this:

    $ meson build -Dspidermonkey=true

Check for the following line in the features summary:

    Run-time dependency mozjs-128 found: YES 128.5.0

Then run:

    $ cd build/
    $ ninja
    $ sudo ninja install

Enjoy.

#### The ECMAScript support is buggy! Shall I blame Mozilla people?

Likely not. The ECMAScript engine provides only the language compiler and some basic built-in objects, and it's more than likely that the problem is on our side in the implementation of some of the HTML/DOM objects (perhaps we just haven't bothered to implement it at all yet). So better tell us first, and if we think it's not our fault we will tell you to go complain to Mozilla (better yet if it does not work in the Mozilla browsers neither ;-).

#### Now, I would still like NJS or a new JS engine from scratch…

...and you don't fear some coding? That's fine then! ELinks is in no way tied to SpiderMonkey, in fact the ECMAScript support was carefully implemented so that there are no SpiderMonkey references outside of `src/ecmascript/spidermonkey.*`. If you want to implement an alternative ECMAScript backend, go ahead - you will just need to write an autoconf detection for it and tie it to `src/ecmascript/ecmascript.c`, which should be easy. We await your patches eagerly.

#### As of 2024

There are 3 javascript engines you could choose from:

- Spidermonkey (mozjs128). Passed tests, but segfaults occur, especially on shutdown.
- QuickJS. Tests also passed. For machines with limited resources, for example DOS machines. Not all memory is released on shutdown. Needs more work.
- MuJS. For fans of MuJS. Not all tests passed. I don't know how to implement missing bits.

By, tests I mean:

    meson ... -Dtest=true ...
    ninja test

There as some assertions in these tests. Small subset of DOM HTML is "covered". If you have some knowledge of these engines, you can help. On some sites ELinks might crash, or slowdown. There is a workaround for this. Files allow.txt and disallow.txt. In the file ~/.config/elinks/allow.txt one can enter prefixes of urls which are allowed. These are urls for text/html pages.

For example:

    file://
    https://www.example.com/news.php

All scripts in local pages are allowed, scripts at https://www.example.com/news.php are also allowed, but other not. If allow.txt is not empty, urls which prefixes do not occur in this file are forbidden. In the file ~/.config/elinks/disallow.txt you can also put prefixes, but this time disallowed. If allow.txt is empty or nonexistent, all scripts allowed, besides pages which prefixes occuring in disallow.txt.

Sample content of disallow.txt:

    http://
    https://www.example.org/

All scripts on pages with protocol http are forbidden. The scripts on pages starting with https://www.example.com/ are also disallowed. When both files exist, you must check it out yourself.

### Feature configuration file (`features.conf`)

This file contains various compile-time configuration settings, which you can adjust below. You can fine-tune the ELinks binary to include really only what you want it to. It acts as a front-end to the configure script in the sense that it is possible to control any features in this file by passing arguments to the configure script. In fact any arguments given to the script will overrule the values set in this file.

There are still some things which are to be adjusted only directly through the configure script arguments though, so check ./configure --help out as well!

All dependency checking is done by the configure script so even though a feature is enabled here it is possible that it will be disabled at compile time if the dependencies are not met. Check the features.log file generated by the configure script to make sure.

#### Notes for users

All features that can be controlled using this file are already set to their default values. The syntax used is hopefully familiar to most people.

# chars start a comment that runs until the end of the line.

The features are controlled by setting the various CONFIG_<FEATURE> variables to either yes or no depending on whether it should be enabled or disabled. So in order to disable bookmark support a line in this file should say:

    CONFIG_BOOKMARKS=no

It is also possible to simply comment out the line in order to disable it. Therefore, if the default doesn't suit you, you can either comment it out or set it to the value you desire.

#### Bookmarks (`CONFIG_BOOKMARKS`)

ELinks has built-in hierarchic bookmarks support. Open the bookmarks manager by pressing s. When bookmarks are enabled, also support for the internal ELinks bookmarks format is always compiled in.

This is a favourite target for disabling in various embedded applications. It all depends on your requirements.

Also read the “The Ultimate Bookmarks Guide” in doc/bookmarks.txt

Default: enabled

#### XBEL Bookmarks (`CONFIG_XBEL_BOOKMARKS`)

ELinks also supports universal XML bookmarks format called XBEL, also supported by e.g. Galeon, various "always-have-my-bookmarks" websites and number of universal bookmark converters.

Frequently, you know you will not need it, then you can of course happily forcibly remove support for it and save few bytes.

Default: enabled if libexpat is found and bookmarks are enabled

#### Cookies (`CONFIG_COOKIES`)

Support for HTTP cookies --- a data token which the server sends the client once and then the client sends it back along each request to the server. This mechanism is crucial e.g. for keeping HTTP sessions (you "log in" to a site, and from then on the site recognizes you usually because of the cookie), but also for various banner systems, remembering values filled to various forms, and so on. You can further tune the ELinks behaviour at runtime (whether to accept/send cookies, ask for confirmation when accepting a cookie etc).

This functionality is usually quite important and you should not disable it unless you really know what are you doing.

Default: enabled

#### Form History (`CONFIG_FORMHIST`)

The famous Competing Browser has that annoying thing which pops up when you submit a form, offering to remember it and pre-fill it the next time. And yes, ELinks can do that too! You will still need to also enable this manually at document.browse.forms.show_formhist.

Many people find it extremely annoying (including pasky), however some others consider it extremely handy and will sacrifice almost anything to get it. It will not do any harm to have this compiled-in as long as you will leave it turned off (which is also the default configuration).

Default: enabled

#### Global History (`CONFIG_GLOBHIST`)

This device records each and every page you visit (to a configurable limit). You can browse through this history in the history manager (press h). Do not confuse this with the "session history", recording history of your browsing in the frame of one session (session history is the thing you move through when pressing back and unback or which you see in the File::History menu).

Global history does not care about the order you visited the pages in, it just records that you visited it, when did you do that and the title of the page. Then, you can see when did you visit a link last time (and what was the title of the target document at that time), links can be coloured as visited etc.

If you disable this feature, you will not lose any crucial functionality, just some relatively minor convenience features, which can nevertheless prove sometimes very practical.

Default: enabled

#### MIME

ELinks uses a MIME system for determining the content type of documents and configuring programs for external handling. By default the option system can be used to configure how media types are handled. More info about how to set up the MIME handling using the option system can be found in the doc/mime.html file.

Below are listed some additional ways to do it.

#### Mailcap (`CONFIG_MAILCAP`)

Mailcap files describe what program - on the local system - can be used to handle a media type. The file format is defined in RFC 1524 and more info including examples can be found in the doc/mailcap.html file.

This is very useful especially for clean interoperability with other MIME-aware applications and fitting nicely into the UNIX system, where this is the standard way of specifying MIME handlers. If you are not interested in that, you can still use the internal MIME associations system, though.

Default: enabled

#### Mimetypes File (`CONFIG_MIMETYPES`)

Mimetypes file can be used to specify the relation between media types and file extensions.

Basically same thing applies here as for the mailcap support.

Default: enabled

#### Gzip and Deflate Decompression (`CONFIG_GZIP`)

This makes ELinks send "Accept-Encoding: deflate, gzip" in HTTP requests and decompress any documents received in those formats. It works with local *.gz files as well.

Default: enabled if zlib is installed and new enough

#### Bzip2 Decompression (`CONFIG_BZIP2`)

This makes ELinks decompress local *.bz2 files. Also, ELinks sends "Accept-Encoding: bzip2" in HTTP requests and decompresses any documents received in that format, but this encoding has not been registered at http://www.iana.org/assignments/http-parameters, so most servers probably won't use it.

Default: enabled if the library is installed

#### LZMA Decompression (`CONFIG_LZMA`)

This makes ELinks decompress local *.lzma files. Also, ELinks sends "Accept-Encoding: lzma" in HTTP requests and decompresses any documents received in that format, but this encoding has not been registered at http://www.iana.org/assignments/http-parameters, so most servers probably won't use it.

To use this, first install LZMA Utils. Version 4.32.5 works; 4.42.2alpha also works and understands a newer LZMA file format. This version of ELinks does not support LZMA SDK from 7-Zip.

Default: disabled

#### IPv6 Protocol Support (`CONFIG_IPV6`)

You know this thing that was designed to obsolete IPv4 but only pasky, weirdos and projects supported with big funds really use. ;-)

Default: enabled if the system supports it

#### URI Rewriting (`CONFIG_URI_REWRITE`)

The goto dialog through which new URIs can be entered is an essential part of browsing in ELinks. This feature makes the dialog more powerful by making it possible to extend how entered text is handled through a set of rewrite rules (see protocol.rewrite options).

There are two types of rules: simple and smart ones.

Simple rewriting rules are basically URI abbreviations, making it possible to map a word to the full URI. They can also be used for hierarchic navigation to ease moving from some nested directory to the parent directory or doing other stuff with the current URI. For example, when you type gg into the goto dialog, you will be materialized at Google's homepage.

Smart rules can take arguments and therefore enable more advanced rewriting. The arguments could be search words to google for or a lookup query for a dictionary. Eg. type gg:Petr Baudis king of ELinks cvs.

This feature is also available in a more powerful form in the Lua and Guile extensions, so if you plan to or already use those, you won't miss anything by disabling this feature (besides easier and better integrated configuration).

Default: enabled

#### BitTorrent Protocol Support (`CONFIG_BITTORRENT`)

The BitTorrent protocol is a protocol for distributing files in a peer-to-peer (P2P) manner. It uses the HTTP protocol for communicating with a central server and a peer-to-peer (P2P) protocol for exchanging file pieces betweens peer downloaders. The integrity of file pieces downloaded from peers are checked using cryptographic hashing (SHA1).

Downloads using BitTorrent are started by first downloading a .torrent file with the MIME type "application/x-bittorrent". The file contains information which enables ELinks to ask a central server, called a tracker, for information about other downloading peers and start downloading from and uploading to them.

At any time, an external handler can always be defined to take precedence of the internal BitTorrent client and the internal client can always be forced by prefixing the URI of the .torrent file with "bittorrent:"

### Note

The BitTorrent support is still experimental.

Default: disabled

#### Local CGI Support (`CONFIG_CGI`)

ELinks can (like w3m or lynx) execute certain executable files stored on the local disks as CGIs, when you target it on them (through a URI of the file scheme). ELinks emulates the complete CGI environment, like the program would be executed by a web server. See the protocol.file.cgi options tree for detailed runtime configuration.

Some people just write their bookmark management application as Perl CGI script and then access it from the web browser using this feature, not needing any web server or so. Therefore, this is a great possible way to extended the browser capabilities.

Even when you compile this in, you need to enable this yet in the configuration, and even then only CGI files passing certain user-defined filters (path-based) will be allowed to be executed (and there are certain other security barriers in place).

Default: disabled, available if setenv() or putenv() is found

#### Data URI protocol (`CONFIG_DATA`)

The data URI protocol is defined in RFC 2397 and allows inclusion of small data items as "immediate" data, as if it had been included externally.

A data URL might be used for arbitrary types of data. The URI

    data:,A%20brief%20note

encodes the text/plain string "A brief note", which might be useful in a footnote link.

Default: enabled

#### Finger User Information Protocol Support (`CONFIG_FINGER`)

The finger protocol is a simple protocol defined in RFC 1288. The server return a friendly, human-oriented status report on either the system at the moment or a particular person in depth such as whether a user is currently logged-on, e-mail address, full name etc. As well as standard user information, it displays the contents of ".plan" file in the user's home directory. Often this file (maintained by the user) contained either useful information about the user's current activities, or alternatively all manner of humor.

It is most often implemented on Unix or Unix-like systems however due to security and privacy reasons it is usually disabled or only allowed locally on the system.

Default: disabled

#### File Service Protocol (`CONFIG_FSP`)

File Service Protocol (FSP) is a very lightweight UDP based protocol for transferring files. FSP has many benefits over FTP, mainly for running anonymous archives. FSP protocol is valuable in all kinds of environments because it is one of the only TCP/IP protocols that is not aggressive about bandwidth, while still being sufficiently fault tolerant.

FSP is what anonymous FTP should be!

See http://fsp.sourceforge.net/ for more info.

Default: disabled

#### File Transfer Protocol Support (`CONFIG_FTP`)

The File Transfer Protocol (FTP) is a software standard for transferring computer files between machines with widely different operating systems.

Many sites that run FTP servers enable so-called "anonymous ftp". Under this arrangement, users do not need an account on the server. By default, the account name for the anonymous access is anonymous. This account does not need a password, but users are commonly asked to send their email addresses as their passwords for authentication (protocol.ftp.anon_passwd), but there is no verification.

See also http://en.wikipedia.org/wiki/Ftp .

Default: enabled

#### Gopher Protocol Support (`CONFIG_GOPHER`)

SFTP See https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol . Requires libcurl.

Gopher is a distributed document search and retrieval network protocol designed for the Internet in RFC 1436. The need for gopher arose in in the early days of the hypertext Internet where the number of documents that were being published in campus and research environments could not easily be distributed using known protocols like FTP because these documents were stored not in one place, but in many computers connected to the Internet.

The support works much like local file browsing with directories (aka. menus) and various file types that can be downloaded and viewed.

It is still very experimental and the CSO phone-book protocol is not implemented.

Default: disabled

#### NNTP Protocol Support (`CONFIG_NNTP`)

Network news transport protocol support makes it possible to access nntp and news servers and read postings. It is still very experimental and is far from being considered a “news reader”.

It is possible to list news groups on a server, articles in a news group and retrieve articles by their number or message-id.

Default: disabled

#### SMB Protocol Support (`CONFIG_SMB`)

ELinks supports browsing over the SMB protocol (URI smb scheme), using the libsmbclient library as back-end. Therefore, in order to have this enabled, you will need to install Samba (or at least just the libsmbclient part, if you can install it separately).

This use of libsmbclient is believed to be immune to the command injection attacks (CVE-2006-5925, bug 841) from which earlier ELinks releases (0.9.0 to 0.11.1) suffered.

Default: disabled

#### Cascading Style Sheets (`CONFIG_CSS`)

Simplistic CSS support. It is still very much in it's infancy so don't expect too much. If you have use of background colors enabled more pages will have the intended background color. Also quite a few additional text attributes are applied. One example is highlighting of search words on Google's cached pages.

There are options to disable both imported style sheets to minimize network traffic and whether to use CSS at all. Also a default style sheet can be defined to control the basic layout in the HTML renderer.

Default: enabled

#### HTML Highlighting (`CONFIG_HTML_HIGHLIGHT`)

Makes it possible to view HTML source with the markup highlighted in colors configurable using CSS. It also makes values of referencing attributes accessible like the href="<uri>" attribute in <a> elements.

The HTML highlighting uses components of an experimental DOM implementation still in progress so enabling this feature will add a considerable amount of code to the compiled binary. On the other hand it will help to debug what will hopefully evolve into the next generation document renderer.

Default: disabled, requires that CSS is enabled

#### ECMAScript (JavaScript) Browser Scripting (`CONFIG_SCRIPTING_SPIDERMONKEY`)

By enabling this feature, certain parts of ELinks, such as the goto URL dialog, may be extended using ECMAScript (aka. JavaScript) scripts. This can be useful to optimise your usage of ELinks.

For example you can define shortcuts (or abbreviations) for URLs of sites you often visit by having a goto URL hook expand them. This can also be achieved with the URI rewrite feature (CONFIG_URI_REWRITE), however it is not as powerful as doing it with scripting.

Default: enabled if Spidermonkey is found

#### Mouse Support (`CONFIG_MOUSE`)

ELinks may be controlled not only by keyboard, but also by mouse to quite some extent. You can select links, menu items, scroll document, click at buttons etc, and it should hopefully work. ELinks supports mouse control by GPM, xterm mouse reporting and TWAIN's twterm mouse reporting.

It is generally nice convenience and doesn't cost too much. However, you can do everything with keyboard as you can with mouse. Also note that the xterm mouse reporting takes control over the terminal so that copy and pasting text from and to ELinks has to be done by holding down the Shift key.

Default: enabled

#### 88 Colors in Terminals (`CONFIG_88_COLORS`)

Define to add support for using 88 colors in terminals. Note that this requires a capable terminal emulator, such as:

- Thomas Dickey's XTerm, version 111 or later (check which version you have with xterm -version) compiled with --enable-88-color.
- Rxvt, version 2.7.9 or later compiled with --enable-88-color.

You will still need to enable this at runtime for a given terminal in terminal options, or set your $TERM variable to xterm-88color - then, ELinks will automatically configure itself to make use of all the available terminal features, while still acting sensibly when you happen to run it in an xterm w/o the 88 colors support.

When enabled, the memory usage is somewhat increased even when running in mono and 16 colors mode (the memory consumption can be especially remarkable when rendering very large documents and/or using very large terminals). However, when you actually run it in the suitable terminal, it looks really impressive, I'd say marvelous!

Default: disabled

#### 256 Colors in Terminals (`CONFIG_256_COLORS`)

Define to add support for using 256 colors in terminals. Note that this requires a capable terminal emulator, such as:

- Thomas Dickey's XTerm, version 111 or later (check which version you have with xterm -version) compiled with --enable-256-color.
- Rxvt, version 2.7.9 or later compiled with --enable-256-color.
- Recent versions of PuTTY also have some support for 256 colors.

You will still need to enable this at runtime for a given terminal in terminal options, or set your $TERM variable to xterm-256color - then, ELinks will automatically configure itself to make use of all the available terminal features, while still acting sensibly when you happen to run it in an xterm w/o the 256 colors support.

When enabled, the memory usage is somewhat increased even when running in mono and 16 colors mode (the memory consumption can be especially remarkable when rendering very large documents and/or using very large terminals). However, when you actually run it in the suitable terminal, it looks really impressive, I'd say marvelous!

Default: disabled

#### True color (`CONFIG_TRUE_COLOR`)

Define to add support for True color. This mode eats a lot of memory.

Default: disabled

#### Terminfo (`CONFIG_TERMINFO`)

Whether to use terminfo for output Unfinished.

Default disabled

#### Ex-mode Interface (`CONFIG_EXMODE`)

The ex-mode interface makes a prompt available when pressing :. The prompt can be used for entering actions like :goto-url and configuration file commands.

The code is still very experimental and lacks much work such as tab completion.

Default: disabled

#### LEDs (`CONFIG_LEDS`)

These are the tiny LED-like indicators, shown at the bottom-right of the screen as [-----]. They are used for indication of various states, e.g. whether you are currently talking through a SSL-secured connection, what is the current input mode (normal or insert), JavaScript errors etc.

Default: enabled

#### Document Marks (`CONFIG_MARKS`)

Makes it possible to set marks in a document and then later jump to them kind of like how fragments in URIs work. It is currently only possible to jump to marks set in the current document.

Default: enabled

#### Debug mode (`CONFIG_DEBUG`)

Assertions are evaluated and will core dump on failure. Some extra sanity checks are done, and some errors will cause core dump instead of just a message. Internal memory leak detection is activated (memory usage will grow), and every allocation/reallocation/free operations will be slower due to extra tests. Lists sanity checks are enabled, so list operations are slower. Hot-key debugging is enabled, it highlights redundant hot-keys in a menu.

This option should be _always_ used by beta testers and developers, it helps to detect many issues. Binary packages maintainers should not use this option in normal situation.

Default: disabled

#### Fast mode (`CONFIG_FASTMEM`)

This option provides a way to generate a faster and smaller binary of a _stable_ version of ELinks. Please do not use it with unstable releases (unless memory footprint, performance and/or binary size are major issues for you).

It disables all assertion tests and sanity checks effectively reducing safety. It disables internal memory allocation routines, directly calling libc functions (so it's much faster, but memory allocation issues and memory leaks will be not detected). It defines fmem_alloc(), and fmem_free() to be in fact alloca() and nothing, providing much faster allocations in routines where they are used

Default: disabled

#### Own C library functions (`CONFIG_OWN_LIBC`)

Enable this to use the various C library stub functions that is part of the portability layer instead of those available in the C library on the system.

It will make the binary slightly bigger and should only be used for testing the portability layer.

Default: disabled

#### Small binary (`CONFIG_SMALL`)

Reduces the size of the binary but also disables a few memory consuming optimizations to make the program much lighter when running.

Part of the size reduction is due to various help text not being compiled in which will affect usability. Also the disabled optimization will make ELinks run slower.

See doc/small.txt for more information about how to reduce the size of ELinks.

Default: disabled

#### Unicode UTF-8 support (`CONFIG_UTF8`)

By enabling this option you get better Unicode support. At present only some parts of ELinks are influenced with this. It includes DOM, plain, HTML renderer and user interface. Beside normal Unicode characters there is support for double-width characters (like Japanese, etc.).

Some features of Unicode are not handled at all. Combining characters is most visible absence. Some features are partially supported. Like line breaking between double-width characters. There is no other detection for determining when to break or not. Character conversions are still incomplete for ECMAScript strings (bug 805), local file names, and IRIs (RFC 3987).

Default: enabled

#### Back-trace Printing (`CONFIG_BACKTRACE`)

Once upon a time, a disaster happens and ELinks crashes. That is a very sad event and it would be very nice to have some means how to diagnose it. In the crash handler, ELinks prints out various helpful things, however the truly important information is _where_ did it crash. Usually, users do not have gdb installed and can't provide a back-trace. However, ELinks can print a back-trace on its own, if the system supports it (currently, it is implemented only for glibc). It is not always accurate, it is useless when the ELinks binary is stripped and it still misses a lot of important information, but it can be sometimes still an indispensable help for the developers.

You should keep this, unless you will strip your ELinks binary anyway, you know you are not going to report back any failures and you care about each single wasted bit.

Default: enabled if the libc supports it (only glibc)

#### Disable Root User (`CONFIG_NO_ROOT_EXEC`)

Browsers are scary monsters used for traveling around in an even more scary world where people indifferently throw garbage files at you and threaten your perfect world. Altho' ELinks is a small monster compared to most browsers, it can still bite your head off and some might consider running it as the root user extremely dangerous. To prevent such usage simply enable this feature.

Default: disabled

Prev |  | Next
The ELinks Manual | Home | Frequently Asked Questions