Sep 16, 2026 by Michael Sjoberg

Next steps for navigation

I'm rethinking navigation in the editor.

Keyboard-first? Yes.

A few useful dialogs? Maybe.

Heavy, Tree-sitter-based lists? No.

The general idea is to avoid maintaining expensive representations of the document just for navigation. No parsing trees. No full-file scans on open just to populate a navigation panel.

Bookmarks will probably be removed.

Next and previous bookmark navigation is useful, but ultimately not that different from find in file. A comment or other recognizable piece of text can already be found using the normal search commands.

Scanning the entire file just to collect bookmarks and display them in a dialog is difficult to justify. That was probably the wrong direction.

I want to keep a list of recent changes.

One idea is to just keep a bounded history of recently changed lines:

RECENT CHANGES
  1248   self._update_position(editor)
   817   if self._loading:
    92   COLORS = {

As edits happen, changed locations can be added to the history.

This makes recent changes effectively free to navigate because the locations are collected as edits happen. There is no need to scan the document when opening the list.

I also want to keep a list of previous cursor positions.

Navigating cursor positions would use browser-history semantics. Moving backward through the history and then making a new jump would discard the old forward history.

Similarly, I want to move to the next and previous occurrence of the word under the cursor.

This avoids opening find in file for a very common form of navigation.

I already have a related command for selecting the next occurrence. The navigation version would use the same basic search operation but move the cursor instead of creating another selection.

Moving to the next and previous changed region is another useful command.

This is basically using the change history without a dialog. A command could simply move to the next or previous changed location relative to the current cursor position. This would be line-based rather than chronological.

The dialog is useful when I want to see where I have been editing. The commands are useful when I just want to cycle through those locations.

Indentation-based navigation is another interesting idea:

class Editor:
    def update(self):
        if self.enabled:
            for item in items:
                process(item)

The editor can simply scan backwards from the current line until it finds the first non-empty line with a lower indentation level. The amount of work then only depends on the distance to the parent.

The Python lexer already has something similar through indentation-based folding combined with the existing move to next and previous fold-header commands. I should probably make this possible in other languages too.