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. Ctrl+R opens a refactoring menu for the current line: replace the endpoint URI of the line, extract the value at the cursor to a property (the value goes to application.properties, in src/main/resources for a Maven layout, and a {{key}} placeholder takes its place), and extract a step to a new route file, called with direct: (YAML and XML routes). 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 Simple expression, the panel follows the cursor within the line: on a function it shows what the function is, an example and its parameters; on ${header.priority} the header too (set in this file, or the description of a component header such as CamelKafkaKey); on an operator after a function, such as contains, the operator and its syntax. Elsewhere on the line it shows the documentation of the line as usual, and outside edit mode the line lists the functions it uses.

In an XML route the panel also follows the cursor: on an attribute name or in its value it shows that attribute (its documentation, default and values), on an element name the element and its required attributes. The uri attribute keeps the documentation of its endpoint.

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.

To convert a whole file, select it in the file list, press F12 and pick Convert to YAML, Convert to XML or Convert to Java. This works on files at rest, without running them: the file is read into the model (the beans of a YAML file as definitions, not created), written in the other DSL into a new file next to it (orders.camel.xml becomes orders.camel.yaml, or the route builder class Orders.java), and read back to check it has the same routes. The new file opens; the original stays as it is, and an existing file is not overwritten. What does not carry over is said at the top of the new file, such as the comments or a part the other DSL’s writer leaves out, and a file that would lose something it cannot say (a lambda processor, a predicate built in Java code) is not converted, with the reason why.