### INTRODUCTION
Any program can only be really useful if it complies to the unix philosophy.
Web browsers (and other tools that work with html, such as feedreaders) are frequent violators of this principle:
* They build in way too much things into one (complex) program, dramatically decreasing the options to do things the way you want.
* They store things in way too fancy formats (xml, rdf, sqlite, ... ) which are hard to store under version control, reuse in other scripts, ...
The uzbl project was started as an attempt to resolve this.
### EDITIONS
"Uzbl" is an umbrella-project consisting of different flavors.
In the future more things may come, but for now:
#### uzbl-core: main component meant for integration with other tools and scripts
* Uses WebkitGtk+ for rendering, network interaction (libsoup). Css, javascript, plugin support etc come for free
* Provides interfaces to get data in (commands/configuration) and out (events): stdin/stdout/fifo/unix sockets
* You see a webkit view and (optionally) a statusbar which gets popuplated externally
* No built-in means for url changing, loading/saving of bookmarks, saving history, keybinds, downloads, ...
* Extra functionality: many sample scripts come with it, on uzbl wiki or write them yourself
* Entire configuration/state can be changed at runtime
* Uzbl keeps it simple, and puts you in charge.
#### uzbl-browser: a complete browser experience based on uzbl-core
* Uses a set of scripts (mostly python) that will fit most people, so things work out of the box. Yet plenty of room for customisation
* Brings everything you expect: url changing, history, downloads, form filling, link navigation, cookies, event management etc
* Advanced, customizable keyboard interface with support for modes, modkeys, multichars, variables (keywords) etc. (eg you can tweak the interface to be vim-like, emacs-like or any-other-program-like)
* Adequate default configuration
* Focus on plaintext storage for your data and configs in simple, parseable formats and adherence to the xdg basedir spec
* Visually, similar to uzbl-core except that the statusbar contains useful things. One window per webpage
#### uzbl-tabbed: wraps around uzbl-browser and multiplexes it
* Spawns one window containing multiple tabs, each tab containing a full embedded uzbl-browser
* Ideal as a quick and simple solution to manage multiple uzbl-browser instances without getting lost
Throughout the documentation, when referring to `uzbl` we mean uzbl-core, unless otherwise specified.
### CONFIGURATION / CONTROL:
The general idea is that uzbl by default is very bare bones. you can send it commands to update settings and perform actions, through various interfaces.
There is a limited default configuration. Please see config.h to see what it contains.
By default, there are *no* keybinds defined at all. (Default keybinds would work counterproductive when you try to customize)
For examples of the possibilities what you can do, please see the sample config(s), and uzbl wiki page.
There are several interfaces to interact with uzbl:
* uzbl --config : will be read line by line, and the commands in it will be executed. useful to configure uzbl at startup.
If you have a file in `$XDG_CONFIG_HOME/uzbl/config` (this expands to ~/.config/uzbl/config on most systems) it will be automatically recognized
* stdin: to write commands into stdin, use `--config -` (or `-c -`)
* interactive: you can enter commands (and bind them to shortcuts, even at runtime)
By default, the behaviour is modal (vi style):
command mode: every keystroke is interpreted to run commands
insert mode: keystrokes are not interpreted so you can enter text into html forms
But if you don't like modal interfaces, you can set `always_insert_mode` and configure a modkey to execute the commands. (emacs style).
There is also support for "chained" commands (multiple characters long) (with backspace/esc shortcuts), and keyworded commands.
Also you can have incremental matching on commands or match after pressing return. (see sampleconfig for more info)
Also, copy paste works when typing commands:
* insert (paste X cliboard)
* shift insert (paste primary selection buffer)
* FIFO & socket file: if enabled by setting their paths through one of the above means, you can have socket and fifo files available which are very useful to programatically control uzbl (from scripts etc).
The advantage of the fifo is you can write plaintxt commands to it, but it's half duplex only (uzbl cannot send a response to you).
The socket is full duplex but you need a socket-compatible wrapper such as socat to work with it.
For example: echo | socat - unix-connect:
When uzbl forks a new instance (eg "open in new window") it will use the same commandline arguments (eg the same --config ), except --uri and--name.
If you made changes to the configuration at runtime, these are not pased on to the child.
#### Uzbl-browser
- default config
- EM
- EM plugins
- bindings/events/requests
#### Uzbl-tabbed
- also has some own keybindings
### COMMAND SYNTAX
Uzbl will read commands via standard input, named fifo pipe (if `fifo_dir` is set) and IPC socket (when `socket_dir` is set).
For convenience, uzbl can also be instructed to read commands from a file on startup by using the `-c` option. Indeed, the config file is nothing more than a list of commands.
Each command starts with the name of the command or an uzbl variable that expands to it. A command is terminated by a newline.
Empty lines and lines that start with the hash sign are ignored by the parser. Command names are always written in lowercase.
The following commands are recognized:
* `set = `
- used for changing variables on the fly
- the changes are effective immediately; for example, setting the variable `uri` will make uzbl start loading, and changing `status_format` will make the status bar react immediately
- if you want to unset a string, use `set` with one space after the equals sign
* `print @`
- use this to print the value of a variable.
* `bind = ` OUTDATED !!!
- sets the character sequence `` to invoke `` when typed interactively in uzbl
- there are a few tricks you can do:
* `` ends with an underscore: the command will only be invoked after pressing return/enter. If the user enters text where `` has the underscore, `%s` in the `` string will be replaced by this text. (optional)
* `` ends with an asterisk: similar behavior as with an underscore, but also makes the binding incremental (i.e. the command will be invoked on every keystroke).
* `` ends on a different character: you need to type the full string, which will trigger the command immediately, without pressing enter/return.
- examples:
* `bind o _ = uri %s`
- uzbl will load the url when you type: 'o '
* `bind /* = search %s`
- a search command which is called on every character typed after the slash, letting you see the search narrow down while typing.
- Hitting return, enter or esc will terminate the search.
* `bind ZZ = exit`
- When you type `ZZ` and nothing else, the exit command will be triggered immediately.
* `back`
* `forward`
* `scroll `
- argument can be `begin`, `end`, or an amount given in pixels(?)
or as a percentage of the size of the view
- set the amount to 100% to scroll a whole page
* `reload`
* `reload_ign_cache`
* `stop`
* `zoom_in`
* `zoom_out`
* `uri `
* `js `
- execute the javascript in ``
- remember that the commands must not contain line breaks
* `script `
- execute the javascript in ``
* `toggle_status`
* `spawn ` TODO explain path-alike expansion
- runs a command; see EXTERNAL SCRIPTS for details
- PATH is searched so giving the full path to commands is not neccessary
- note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
* `sh `
- runs a shell command by expanding `%s` in the `shell_cmd` variable with the specified command; primarily useful as a shortcut for `spawn sh -c `
- note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
* `sync_spawn `
* `sync_sh `
- these are synchronous variants of `spawn` and `sh`, which means uzbl will wait for them to return
- you should only need to use these manually if you want to use a chain command in a handler that wants output from the command it runs
* `talk_to_socket `
- lets uzbl talk to a socketfile
* `exit`
* `search `
* `search_reverse `
- search with no string will search for the next/previous occurrence of the string previously searched for
* `toggle_insert_mode ` TODO new plugin based syntax
- if the optional state is 0, disable insert mode. If 1, enable insert mode.
* `dump_config`
- dumps your current config (which may have been changed at runtime) to stdout, in a format you can use to pipe into uzbl again (or use as config file)
* `keycmd `
* `keycmd_nl `
- keycmd sets the interactive command buffer to ``. If the given string is a valid binding, it will execute. `Keycmd_nl` is like `keycmd`, but it also emulates a press of return, causing bindings with a parameter to execute. For example, `keycmd_nl o google.com` would load the said url if you have a binding like `bind o _ = uri %s`.
* `keycmd_bs`
- erase (backspace) one character from the command buffer
* `chain ..`
- use for chaining multiple commands
- remember to quote the commands; one command must come as one parameter
- if you use `chain` with a handler script which must return some output (such as a cookie handler -- uzbl will wait for and use its output), use sync_spawn or sync_sh instead of spawn or sh in the command that should give the output
* `event [event_details]`
- send custom event
* `menu_add