DIESEL

DIESEL is a compact, string-expression macro language that has been part of AutoCAD since Release 12 in 1992. Created by Autodesk co-founder John Walker, it was designed from the start as a deliberately small language — just enough to evaluate expressions inside the AutoCAD status bar and menu macros, without requiring the complexity of AutoLISP. More than three decades later, DIESEL still ships with AutoCAD and remains the simplest way to embed dynamic, computed text into the AutoCAD UI and, since AutoCAD 2005, into the drawings themselves via the Field feature.

What the Name Means

The expansion of the DIESEL acronym is itself a minor piece of AutoCAD folklore. Walker’s original documentation on fourmilab.ch glosses DIESEL as the “Dumb Interpretively Evaluated String Expression Language” — a self-deprecating nod to how intentionally limited the language is. Autodesk’s official customization documentation generally uses the more corporate expansion “Direct Interpretively Evaluated String Expression Language”. Both forms appear widely in the literature; the language itself is identical in either reading.

History & Origins

By the early 1990s, AutoCAD had grown from a simple drafting tool for MS-DOS PCs into a serious CAD platform with a rich customization story: AutoLISP (introduced in the 1980s), SCR script files, and menu (MNU) files. But Walker wanted a way to let users customize the AutoCAD status line without invoking the full AutoLISP interpreter on every redraw. Evaluating a Lisp expression several times a second, purely to recompute the string displayed on the bottom of the screen, was heavier machinery than the job needed. And on AutoCAD LT — Autodesk’s lower-priced sibling product — AutoLISP historically was not available at all, so customization hooks that relied on Lisp were off the table.

DIESEL was Walker’s answer: a small, fixed-function expression evaluator that reads system variables and environment values, does simple arithmetic and string manipulation, and produces a string. It shipped with AutoCAD Release 12 in 1992, alongside the MODEMACRO system variable that served as its canonical invocation point. Walker subsequently released the DIESEL source code into the public domain on his personal site fourmilab.ch, and his documentation describes the design goal plainly: provide “a rudimentary macro expansion facility … without the complexity of a full language such as Lisp or FORTH.”

That framing — not a full language — is the key to understanding DIESEL. Almost every feature decision in the language can be read as “what is the minimum we need to compute a string, and what can we leave out?”

Design Philosophy

Everything Is a String

In DIESEL, every value — every function argument, every function return — is a string. There are no numeric, boolean, or list types that live separately from their string representation. Arithmetic operators accept strings that parse as numbers, comparison operators treat their arguments as numbers or as strings depending on the function, and logical results come back as "1" or "0". This makes DIESEL easy to embed directly into text output, which is, after all, the point: the expression is a template that gets expanded into a string and dropped into the status bar or onto the drawing.

No User-Defined Anything

DIESEL has:

• No user-defined functions. Its built-in function set is fixed at roughly 27 operations and cannot be extended from inside the language.
• No user-defined variables. The only “variables” are AutoCAD system variables (read via $(getvar,...)) and OS environment variables (read via $(getenv,...)), and even those are read-only from DIESEL.
• No loops. Control flow consists of if and short-circuiting boolean operators, and that is the whole of it.

The lack of mutable state is partly a reentrancy decision — DIESEL expressions can be re-evaluated on every screen update without worrying about accumulating side effects — and partly just a way to keep the implementation tiny.

$(function, arg, arg) Syntax

A DIESEL expression is a function call of the form:

$(function, arg1, arg2, ...)

Function calls may be nested. Inside menu macros, DIESEL is introduced with the $M= prefix. Autodesk’s DIESEL reference documents a limit of ten parameters per function call, counting the function name itself as one — a cap that occasionally forces authors to flatten complicated conditionals into nested expressions.

A short illustrative example that might be assigned to MODEMACRO to display the current layer and a snap status indicator looks roughly like this:

Layer: $(getvar,clayer)   Snap: $(if,$(getvar,snapmode),ON,OFF)

Each $(…) is evaluated and replaced with its string result, and anything outside the expressions is passed through verbatim.

Key Features

Built-in Function Categories

DIESEL’s function library is small but covers the basics needed for status-bar and field text:

• Arithmetic: +, -, *, /, and fix (truncate-to-integer).
• Comparison: =, <, >, !=, <=, >=, which compare their arguments and return "1" or "0".
• Logical / bitwise: and, or, xor.
• String: eq (string equality), strlen, substr, upper, index, nth.
• System and environment access: getvar (read an AutoCAD system variable) and getenv (read an OS environment variable).
• Formatting: rtos (real-to-string with units and precision), angtos (angle-to-string), edtime (format a Julian date).
• Control / utility: if, eval.

MODEMACRO and the Status Line

The primary entry point for DIESEL historically is the MODEMACRO system variable. Setting MODEMACRO to a DIESEL expression causes AutoCAD to re-evaluate that expression as part of drawing the status line, writing the result into the leftmost user-defined area. Autodesk documents a 240-character limit on the rendered result and notes that MODEMACRO is reset by setting it to a single period (.). On AutoCAD for Mac and AutoCAD LT for Mac, the Autodesk documentation explicitly notes that MODEMACRO is not supported.

Menu Macros via $M=

Inside a menu macro, a $M= prefix tells AutoCAD to pass the rest of the macro through the DIESEL evaluator before executing it. This allows a single menu item to branch at runtime:

^C^C$M=$(if,$(getvar,tilemode),mspace,pspace)

This macro — a stylized example, not a production snippet — uses DIESEL to inspect TILEMODE and then issue either the MSPACE or PSPACE command accordingly.

Fields (AutoCAD 2005 and later)

Starting in AutoCAD 2005, the FIELD command lets authors embed live, evaluated content into drawing text, attributes, and tables. Fields can be driven by DIESEL expressions, which dramatically expands the language’s practical reach: a title block can show the current date, a revision field can reflect a system variable, or a dimension note can auto-update from a named setting. This is why many AutoCAD users who have never directly edited MODEMACRO have still touched DIESEL without realizing it — they did it through the Field dialog.

User System Variables (USERI / USERR / USERS)

AutoCAD exposes a small set of user-settable system variables — USERI1 through USERI5 (integers), USERR1 through USERR5 (reals), and USERS1 through USERS5 (strings) — which store values that persist per drawing. These pair naturally with DIESEL: AutoLISP or a user command can set USERI1, and a DIESEL expression in MODEMACRO or a Field can read it back with $(getvar,useri1). This is the closest thing DIESEL has to program-wide mutable state.

A Slightly Larger Example

A MODEMACRO that shows the current layer, a space/paper indicator, and a snap status indicator might look like:

$(if,$(getvar,tilemode),Model,Paper) | Layer: $(getvar,clayer) | Snap: $(if,$(getvar,snapmode),ON,OFF)

Each time AutoCAD redraws the status bar, the three $(getvar,...) calls re-read their system variables, the $(if,...) forms pick their branch, and the result is a freshly rendered status string. There is no loop, no variable assignment, no persistent state — the entire contents of the line are recomputed from current system state on each pass.

Relationship to AutoLISP

AutoLISP and DIESEL are often mentioned together but occupy very different niches within AutoCAD customization:

The typical rule of thumb is: if the task is “compute a string for the status bar, a menu macro, or a field,” reach for DIESEL; if it is anything more ambitious, reach for AutoLISP (or Visual LISP, or ObjectARX, or .NET).

Current Relevance

DIESEL is still a current part of AutoCAD. Autodesk continues to publish reference pages for DIESEL functions and MODEMACRO in the AutoCAD 2022, 2023, and 2024 Customization Guides, and the language has not been formally deprecated. In day-to-day use, however, its centrality has shifted:

• Menu macros are no longer the primary customization surface: the CUI (Customize User Interface) system and the ribbon have largely replaced the old MNU/MNS menu files that were DIESEL’s first big job.
• Status-line customization via MODEMACRO remains a niche but real use case, especially in shops that want on-screen readouts of project-specific state.
• Fields, introduced in AutoCAD 2005, are where most contemporary users encounter DIESEL, often via the Field dialog rather than by hand-typing expressions.

Outside of AutoCAD proper, BricsCAD and progeCAD both publish their own DIESEL language references as part of their AutoCAD-compatibility stories, so DIESEL knowledge continues to pay off across the AutoCAD-compatible CAD ecosystem.

Why It Matters

DIESEL occupies an interesting corner of programming-language history:

1. A language that knew how small it wanted to be. Most languages start small and grow; DIESEL was scoped as tightly as possible from the outset and has largely stayed that way. Walker’s own documentation treats the minimalism as a feature, not a limitation.
2. An antidote to reaching for a full language. Where a hasty designer might have reused AutoLISP for status-line expressions, Walker built a separate tool sized to the actual job. The result is a macro facility that runs cheaply on every redraw and never has to worry about reentrancy bugs in user code.
3. Longevity inside a vertical ecosystem. DIESEL is not a language anyone writes general-purpose software in, but it has sat quietly inside AutoCAD for more than thirty years and continues to be used today. That is a particular kind of language success — embedded, domain-specific, and almost invisible, but load-bearing.
4. The template-expansion pattern, ahead of its time. DIESEL expressions are essentially templates with callable functions — a pattern later popularized in configuration languages, templating engines, and expression DSLs. Its $(fn,arg,arg) form is idiosyncratic, but the idea of “drop evaluator calls into an otherwise-static string” has reappeared many times since.

For anyone doing serious AutoCAD customization, DIESEL is still worth learning: the investment is genuinely small (the entire function reference fits on a handful of pages), and the payoff — dynamic status bars, smart menu macros, and live field text — is disproportionately large.