How awesome uses Lua for configuration and extension

awesome is configured and extended in Lua. The window manager itself is a framework built around a documented Lua API: you define behavior by editing a Lua configuration file, and you add features by loading or writing Lua modules. This applies to anyone running awesome on X who wants fine-grained control over their graphical environment, and it assumes you are comfortable editing a text file and reloading the window manager rather than clicking through a settings dialog.

The core mechanism

awesome is described as a "framework window manager" that is "heavily extensible using the Lua programming language," and it ships a documented API "to configure and define the behavior of your window manager." In practice this means:

• Configuration is code. Instead of a declarative settings file with fixed keys, your config is a Lua script. You set variables, call API functions, and wire up callbacks.
• Behavior is defined through the API. Keybindings, rules for how windows are managed, and layout behavior are expressed by calling documented functions rather than by toggling built-in options.
• Extension happens in the same language. Because the config layer and the extension layer are both Lua, adding a feature and configuring it use the same toolset.

This is the key difference from window managers where you configure a fixed feature set and extend it in a separate language or plugin system.

What you can configure and extend

The site lists a range of Lua extensions that add features on top of the base window manager:

Because these are Lua extensions rather than hardcoded features, the same API you use to configure them is available for writing your own.

Tags instead of workspaces, and why it matters for config

awesome "uses tags instead of workspaces," which "allow to place clients on several tags, and display several tags at the same time." It also "does not distinguish between layers: there is no floating or tiled layer."

For configuration, this means your Lua config deals with tag membership and visibility as first-class concepts, and you are not choosing between a floating mode and a tiled mode as separate systems. If you are coming from a workspace-based window manager, expect to express your setup in terms of tags when you write the config.

Other properties relevant to extending it

• Keyboard-driven: "No mouse needed: everything can be performed with the keyboard," so bindings defined in Lua are the primary interface.
• Multihead: "Real multihead support (XRandR) with per screen desktops (tags)" — configuration is per screen.
• Standards: It implements EWMH, XDG Base Directory, XEmbed, Desktop Notification, and System Tray, which affects how extensions interact with the rest of the desktop.
• D-Bus support is included, giving extensions a way to communicate with other applications.
• Licensing: GNU GPLv2, relevant if you plan to distribute extensions.
• Performance basis: It was the first window manager to use the asynchronous XCB library instead of the synchronous Xlib, which the project says makes it "less subject to latency compared to other window managers."

Practical implications

If your goal is to understand how awesome uses Lua, the short version is: there is no separate configuration format and no separate plugin language. You edit Lua, you call a documented API, and you extend the same way you configure. The trade-off is that control comes from writing code, which the project frames as being "primarily targeted at power users, developers and any people dealing with every day computing tasks and who want to have fine-grained control on their graphical environment."

For the exact API surface and current version details, the site points to "awesome 4.3 documentation (stable)" and separate docs for the latest git version.