I got tired of the loop. You’re writing a page extension, you need to know what a control is called on the Customer Card, so you open VS Code, wait for the AL extension to load, navigate to the page object, scroll through 400 controls, find the one you want, copy the name, go back to your code. Two minutes for a piece of information that should take two seconds.
AL Explorer is a terminal UI that lets me look up any symbol in any .app package instantly. I type, I see results, I move on.
What it actually is
It’s a ratatui-based TUI with three panes: packages on the left, objects in the centre, details on the right. When you launch it, it connects to the al-lsp daemon over a Unix socket and gets access to the full symbol index that’s already loaded in memory.
That last part matters. The daemon has already parsed every .app file in your .alpackages/ directory at startup. The symbol data sits in a DashMap — a sharded concurrent hashmap that gives you lock-free reads. When AL Explorer queries “show me all Page objects in the Base Application package,” it’s not parsing anything. It’s filtering an in-memory index. The response comes back before the terminal has time to flicker.
I measured this once out of curiosity. A filtered search across 30,000+ symbols from 14 packages takes about 400 microseconds. I couldn’t get a meaningful measurement on individual lookups because they were below the timer’s resolution.
Tab switches panes, j/k navigates, / searches, Enter selects, Esc goes back
Interactive demo works best on a wider screen.
Open demo in new tab →How I use it
The thing I reach for it most is checking field names. I know the table is called “Sales Header” and I know there’s a field for the customer’s purchase order number, but I can never remember if it’s "Your Reference" or "External Document No." or something else entirely. I type sales header, arrow down to the table, and the right pane shows me every field with its ID, name, and type. Done.
Page extension placement is the other one that comes up constantly. Page controls in AL have names that don’t always match the field they display. The "Sell-to Customer No." field might live inside a group called "General" on the page. I need the exact group and control names for my addafter or addbefore placement. AL Explorer shows me the full control tree, so I stop guessing.
I also use it a lot when working with ISV packages. You need to subscribe to one of their events or extend one of their pages, and you have no idea what’s in the .app file. AL Explorer shows me every object, every procedure signature, every event publisher. Beats emailing the vendor and waiting two days for a PDF.
The keyboard
Tab moves between panes. Within a pane, arrows navigate. [ and ] cycle through object kinds — so if I’m looking at the Base Application package, I can flip between Tables, Pages, Codeunits, Enums without scrolling through a flat list. / opens the search bar. g toggles global search across all packages.
Double-clicking an object (yes, it handles mouse input via crossterm) opens the source in Zed. If the object comes from a package rather than your workspace, AL Explorer generates a virtual .al file from the symbol data and opens that instead. It’s read-only so you can’t accidentally edit a generated file.
Why it’s a separate binary
AL Explorer doesn’t link against al-core or any of the analysis libraries. It’s a pure JSON-RPC client — about 800 lines of ratatui layout code and a socket connection. This is a deliberate architecture choice. The daemon does the heavy lifting. The TUI just renders what the daemon sends back.
This means AL Explorer compiles in under 3 seconds and has almost no dependencies beyond ratatui and crossterm. If I wanted a web-based symbol browser or a VS Code panel doing the same thing, I’d write another thin client against the same socket. The data and speed wouldn’t change.
The honest version
It’s not going to replace your IDE’s go-to-definition. If you’re already in Zed with the AL extension running, you have the same symbol data through hover and completions. AL Explorer is for when you’re not in the editor. Planning in a terminal, writing a spec, poking around an unfamiliar package. Lookup tool, not an editor.
For that specific job though, nothing I’ve tried comes close. The index is already warm from the daemon, so every query is just a hashmap read. I keep a tmux pane with it running. I check things there more than I open package files, which honestly surprised me when I noticed it.