# Editors, LSP, and Debuggers

### Editors, LSP, and Debuggers

You can write Zig code in any text editor.

A Zig source file is plain text. It usually ends with:

```text
.zig
```

For example:

```text
main.zig
```

You do not need a special IDE to learn Zig. A simple editor and a terminal are enough. But a good editor setup makes learning easier because it can show errors, format code, and help you move around a project.

#### The Basic Setup

For this book, you need three things:

| Tool | Purpose |
|---|---|
| Text editor | Write Zig source code |
| Terminal | Run Zig commands |
| Zig compiler | Compile, run, test, and format code |

The editor is where you write code.

The terminal is where you run commands such as:

```bash
zig run main.zig
zig test main.zig
zig fmt main.zig
zig build
```

The compiler checks and builds your code.

#### Choosing an Editor

Common choices include:

| Editor | Notes |
|---|---|
| VS Code | Popular, easy setup, many extensions |
| Vim or Neovim | Fast, keyboard-driven, configurable |
| Emacs | Powerful, configurable |
| Zed | Modern editor with good language tooling |
| Helix | Terminal editor with built-in LSP support |
| Sublime Text | Lightweight graphical editor |
| CLion | Full IDE, useful for C/C++ style workflows |

For absolute beginners, VS Code is often the easiest place to start.

For terminal users, Neovim, Helix, or Emacs are also good choices.

The editor does not change the Zig language. Choose the tool you can use comfortably.

#### What an LSP Is

LSP means Language Server Protocol.

That sounds complicated, but the idea is simple.

An LSP server is a program that helps your editor understand your code.

With Zig, the common language server is called ZLS, short for Zig Language Server.

An editor plus ZLS can provide features such as:

| Feature | Meaning |
|---|---|
| Error messages | Show mistakes while you type |
| Go to definition | Jump to where a function or type is defined |
| Hover information | Show type or documentation near the cursor |
| Autocomplete | Suggest names while typing |
| Rename symbol | Rename a variable or function safely |
| Formatting | Format code using Zig style |

Without LSP, your editor is mostly editing text.

With LSP, your editor understands more about the program.

#### Installing ZLS

ZLS is usually installed separately from Zig.

Your editor extension may help install it, or you may install it manually.

The exact method depends on your system and editor. The important point is this:

```text
Zig compiler and ZLS should match closely.
```

If your Zig compiler is version `0.16.x`, use a ZLS version intended for that Zig version.

If ZLS and Zig are mismatched, you may see strange editor errors even when the program builds correctly.

#### VS Code Setup

A typical VS Code setup is:

1. install Zig
2. install a Zig extension
3. install or configure ZLS
4. open your project folder
5. edit files under `src/`

After setup, VS Code should recognize `.zig` files.

When you open a file like:

```text
src/main.zig
```

you should get syntax highlighting and language features.

A small test file:

```zig
const std = @import("std");

pub fn main() void {
    std.debug.print("Hello from editor setup!\n", .{});
}
```

Run it from the terminal:

```bash
zig run src/main.zig
```

If that works, your compiler is installed correctly.

If your editor also shows Zig syntax colors and helpful errors, your editor setup is working too.

#### Formatting Code

Zig includes an official formatter.

You can format a file manually:

```bash
zig fmt src/main.zig
```

Many editors can run this automatically when you save the file.

This is useful because Zig code has a standard style. You do not need to spend time deciding indentation rules.

For example, messy code like this:

```zig
pub fn main(  ) void{
}
```

becomes:

```zig
pub fn main() void {}
```

Use the formatter early. It keeps your examples clean and easier to compare with the book.

#### Reading Errors in the Editor

A good editor may show compiler or language-server errors inline.

For example:

```zig
const age: u32 = "hello";
```

This is wrong because `age` is declared as a number, but `"hello"` is text.

The editor may underline the error before you even run the program.

That is helpful, but remember: the compiler is the final authority.

If your editor says something is wrong but `zig build` succeeds, your editor or ZLS may be misconfigured.

If `zig build` fails, trust the compiler error.

#### Debuggers

A debugger lets you pause a running program and inspect it.

With a debugger, you can:

| Action | Meaning |
|---|---|
| Set a breakpoint | Stop at a chosen line |
| Step over | Run the next line |
| Step into | Enter a function call |
| Inspect variables | See current values |
| View stack frames | See how the program reached this point |

Zig can work with native debuggers such as LLDB and GDB.

The common choices are:

| Platform | Common debugger |
|---|---|
| macOS | LLDB |
| Linux | GDB or LLDB |
| Windows | Visual Studio debugger, WinDbg, or CodeLLDB setups |

For beginners, you do not need to start with a debugger immediately. You can learn a lot with `std.debug.print`.

But as programs grow, a debugger becomes useful.

#### Debug Builds

Debuggers work best with debug builds.

By default, Zig builds in debug mode.

For example:

```bash
zig build-exe main.zig
```

This keeps debug information and safety checks.

An optimized release build like this:

```bash
zig build-exe main.zig -O ReleaseFast
```

may be harder to debug because the compiler changes the program to make it faster.

Variables may disappear. Lines may not execute in the exact order you expect. Some functions may be inlined.

While learning, use debug mode.

#### Print Debugging

The simplest debugging tool is printing values.

Example:

```zig
const std = @import("std");

pub fn main() void {
    const a = 10;
    const b = 20;
    const result = a + b;

    std.debug.print("a = {}, b = {}, result = {}\n", .{ a, b, result });
}
```

Output:

```text
a = 10, b = 20, result = 30
```

This is not fancy, but it is effective.

When a program behaves incorrectly, print the values near the problem. Check whether the program’s state matches what you expected.

#### Compiler First, Editor Second

Do not depend completely on editor features.

Always know how to run the compiler yourself:

```bash
zig build
```

or:

```bash
zig run src/main.zig
```

This matters because editor tools can be stale, misconfigured, or using the wrong Zig version.

The command line gives you the clearest ground truth.

#### A Good Beginner Workflow

A simple workflow looks like this:

| Step | Action |
|---|---|
| 1 | Open the project folder in your editor |
| 2 | Edit `src/main.zig` |
| 3 | Save the file |
| 4 | Run `zig fmt` or format on save |
| 5 | Run `zig build` or `zig run` |
| 6 | Read compiler errors carefully |
| 7 | Fix one problem at a time |

Do not try to fix ten errors at once.

Often, one syntax mistake causes several later errors. Fix the first error, then compile again.

#### What You Should Remember

You can write Zig in any editor.

A good setup includes syntax highlighting, ZLS, formatting, and a terminal.

ZLS helps your editor understand Zig code, but the Zig compiler is still the final authority.

Use `zig fmt` to keep code clean.

Use debug builds while learning.

Use `std.debug.print` first, then learn a debugger when your programs become larger.