Camel TUI Source Editor

The left panel lists the files of the integration’s project, and the right panel shows the selected file with syntax highlighting. Tab switches between the two panels, and you can drag the border between them with the mouse.

Press Enter to view a file, or F4 to edit it. The editor is a plain-text editor with helpers for Camel routes: undo and redo, moving and duplicating YAML blocks, smart Home, and word navigation. In YAML routes, Ctrl+R opens a refactoring menu for the current line. Ctrl+S saves and keeps editing, F5 saves and closes, and Esc cancels (and asks before it discards unsaved changes). A running integration in dev mode reloads the saved file.

While the integration runs, a column after the line numbers shows what the processors on each line do: the exchanges they handled, and how many failed (✗, in red). The mean time is shown too, when it is 1 ms or more. The numbers follow the running integration, so the source reads as a heat map of the route: where the messages go, and where they fail.

In the example the timer fired 227 times; the filter let 137 of those through to log:big, and 27 orders failed at throwException. You see this without leaving the code, and without adding a single log statement.

The column keeps its width, so the code does not move as the numbers grow. It works for YAML, Java and XML routes, as camel run records the source line of every processor.

The editor checks your routes while you type: endpoint URIs and their options against the Camel catalog, Simple expressions, the YAML DSL schema, and a to whose URI holds ${...} and should be a toD. Java routes are read without compiling them, so endpoints built with the endpoint DSL or from a constant are checked too.

The problems are marked as soon as a file opens, before you change anything: a red ✗ on the line, and the count in the title. The panel at the bottom says the problem of the selected line, and F9 goes to the next one.

In the editor, a line with a problem has a red line number, the title shows how many errors there are, and the Error panel at the bottom says what is wrong with the line the cursor is on. They are checked again as you type, and F9 jumps to the next problem.

Many problems say how to fix them: an option typo (siz instead of size), an enum value a letter off, a to that should be a toD, ${key} where the property placeholder {{key}} is meant, or a Simple function the error names the right one of (${bdy} for ${body}). For these, the Error panel shows the fix, and Shift+F9 applies it to the line:

The same fixes are part of the result of the camel_validate_source MCP tool, so an AI agent can apply them too.

When a problem has no quick fix, Shift+F8 asks the AI. The file is saved as it is, and the AI panel opens with the question already written: the file, the line, the problem, and how to fix it. Press Enter to send it, or change it first.

The AI changes the file with the same tools an AI agent uses over MCP, and every change waits for you: the dialog shows what the AI wants to change, d shows the diff, Enter applies it and Esc rejects it.

A file the AI writes is checked like one you save, and a write that brings new problems is refused, so the AI gets the problems back and can try again. The view shows the file as the AI wrote it as soon as you apply the change. With /write live in the AI panel, you can also watch the AI type its change in the editor; see Watching the AI edit.

The AI panel works with a hosted provider or with a local model through Ollama; see Choosing an AI provider.

In edit mode, Tab completes what the cursor is on. Type to filter the list (an exact or prefix match comes first), use Up/Down to choose, and Enter to accept. The details panel shows the documentation of the choice: its type, default value and description.

What can be completed:

The panel at the bottom shows the documentation of the line the cursor is on, from the Camel catalog: the component and the options of an endpoint, the EIP of a step, or the language of an expression.

This makes an unfamiliar route easy to read without leaving the terminal.

What the project knows about the line comes first. A property placeholder shows its value, from the .properties files of the project, or the default that is used when it is not set:

A line that refers to a bean (bean:name, .bean(MyBean.class), ref: name, #class:com.foo.MyBean…​) says where the project declares it (@BindToRegistry, @Named, @Component, @Bean, or the beans of a YAML or XML file), and shows a ↵ name jump link: Enter goes to the declaration.

In a YAML route, the title shows where the cursor is in the route, such as route > from > choice > when > setHeader:

The line numbers of the lines you changed since the file was opened are green (see the picture above), so you see at a glance what you changed. F7 shows all the unsaved changes as a diff, with the line numbers of the file. F7 or Esc returns to the editor.

When you open the source of a route from the Diagram or Route tab (c), Space shows that route in YAML, Java or XML. The title shows the three formats, and the one marked with * is the file the route is written in.

This is handy to see how a route reads in another DSL, or to copy it into a file of another DSL. Press p for plain mode, which hides the line numbers and borders for easy copying.