Split editor.rs into smaller modules

[GoldStrikeArch]

crates/editor/src/editor.rs is ~30k lines and growing (I remember it was around 20k in September 2025 😅 ). At that size GitHub stops syntax-highlighting it, every diff lands in one file, and it's hard to tell whether a change is touching input, completions, or rendering glue. Editor is central for real reasons (GPUI entity, view, input handler, workspace item, event source), so a semantic refactor is genuinely hard, but the file size is making review and contribution worse than it needs to be.

I pushed a branch that takes the smallest possible step: compare link. This is just a mechanical split into a different files and public API is unchanged. Contiguous impl Editor blocks moved into child modules under crates/editor/src/editor/, this is how it looks in the file tree:

crates/editor/src/editor/
├── input.rs
├── selections.rs
├── completions.rs
├── code_actions.rs
├── navigation.rs
├── diagnostics.rs
├── folding.rs
├── git_diff.rs
├── diff_review.rs
├── configuration.rs
└── git_integration.rs

After the split:

• editor.rs: 16,938 (from 30,482)
• editor/navigation.rs: 5,627 — already too big, obvious next split
• element.rs: 14,089, untouched (but should be splitted as well)
• editor_tests.rs: 37,516, untouched

I didn't try to split Editor into separate runtime objects. Most methods need some mix of &mut Editor, &mut Window, &mut Context<Editor>, snapshots, cx.notify(), cx.emit(...), and async tasks that upgrade a WeakEntity<Editor> later, so decomposing that into independent components hits borrow and lifecycle issues fast.

Would maintainers take a mechanical split like this as a first step? If so, the natural follow-up is the same breaking up of element.rs file which is also super huge ATM

cc @ConradIrwin

[ConradIrwin]

I'm not personally interested in working on this (but I don't speak for everyone).

[SomeoneToIgnore]

I am not interested to break it all at once (yet), as it will create a lot of conflicts with the existing PRs.

Yet, already trying to place the new code into separate modules already, e.g. editor.rs: https://github.com/zed-industries/zed/pull/54100/changes#diff-a3da3181e4ab4f73aa1697d7b6dc0caa0c17b2a187fb83b076dfc0234ec91f54

Overall, would be nice to have both editor.rs and element.rs split into submodules based on their "topics": git, diagnostics, etc.
Both sets of submodules could be flat, as guessing the hierarchy from the first try might be too much.
editor_tests.rs is a good benchmark, it should stay and keep on periodically growing.

I see the way forward with small, incremental, split offs of the existing code into modules, one by one.
For instance, git-related part of element.rs, then git-related part of editor.rs, then something else.

---

On a related note, Editor struct has quite a swarm of fields that are somewhat misconfigured (e.g. lost on .clone() and mode change) or misused.
That all, along with the related state, IMO should be moved into corresponding EditorMode variants instead.

[GoldStrikeArch]

@SomeoneToIgnore

Overall, would be nice to have both editor.rs and element.rs split into submodules based on their "topics": git, diagnostics, etc.
Both sets of submodules could be flat, as guessing the hierarchy from the first try might be too much.

Yes, incremental splits is possible and a good way forward. We can create an issue (story-like) for the incremental split, wdyt?
Do you think we should do it together (both element.rs and editor.rs) for a single "topic" (like the diagnostics) as "one step"? IMO it makes sense to start with editor.rs (as it is bigger) first and then move to element.rs or vise-versa

[GoldStrikeArch]

@SomeoneToIgnore

If you see the same but think there are more low-hanging fruits to split off, seems ok, if not — element.rs seems a better choice?

I think we can also extract those things out of editor.rs:

• highlights.rs

pub fn highlight_rows<T: 'static>(
    &mut self,
    range: Range<Anchor>,
    color: Hsla,
    options: RowHighlightOptions,
    cx: &mut Context<Self>,
) {
    // ...
}

• lsp.rs

pub fn rename(
    &mut self,
    _: &Rename,
    window: &mut Window,
    cx: &mut Context<Self>,
) {
    // ...
}

• clipboard.rs

pub fn cut_common(
    &mut self,
    cut_no_selection_line: bool,
    window: &mut Window,
    cx: &mut Context<Self>,
) -> ClipboardItem {
    // ...
}

• workspace.rs

pub fn new_in_workspace(
    workspace: &mut Workspace,
    window: &mut Window,
    cx: &mut Context<Workspace>,
) -> Task<Result<Entity<Editor>>> {
    // ...
}

• line_manipulation.rs
  Things like

pub fn join_lines_impl(
    &mut self,
    normalize_whitespace: bool,
    window: &mut Window,
    cx: &mut Context<Self>,
) {
    // ...
}

• edit_prediction.rs
  Things like

pub fn refresh_edit_prediction(
    &mut self,
    debounce: bool,
    user_requested: bool,
    window: &mut Window,
    cx: &mut Context<Self>,
) -> Option<()> {
    // ...
}

Looks like those can be extracted the same way as we did before and combined would have ~5k lines. WDYT?

[SomeoneToIgnore]

Not sure about some of them: definitely not fond of introducing lsp.rs as that seems more like a step towards module hierarchy and we have a bunch of LSP-related modules already; workspace.rs is also a very generic odd name and we have another workspace.rs in the codebase; highlights.rs could be questionable too, I guess, given that it's both tree-sitter and LSP-related?

The rest seems fine, I guess, but I would like to see the end of it given that we've achieved the original goal already and the rest of the splitting seems to procure smaller and smaller gains?
Maybe, one last editor.rs split off PR is fine, if you feel like it.

[GoldStrikeArch]

Ok, makes sense. I will try to extract edit_predction and maybe something else as those will give the most gains. After that we can think about splitting element.rs

[GoldStrikeArch]

Hi @SomeoneToIgnore,

So, looks like we are done with editor.rs for now. I also looked into element.rs and looks like we can split some parts of it like that:

• headers.rs
  Things like:

pub(crate) fn render_buffer_header(...) {
    // ...
}

pub fn header_jump_data(...) -> JumpData

• invisible_lines.rs

impl LineWithInvisibles {
    fn from_chunks<'a>(...) -> Self {
        // ...
    }
}

fn draw_invisibles(...) {
    // ...
}

• mouse.rs

fn mouse_left_down(...) {
    // ...
}

fn mouse_moved(...) {
    // ...
}

• blocks.rs (or render_blocks.rs or maybe block_layout.rs not sure which one is better here)

fn render_block(...) -> AnyElement {
    // ...
}

fn render_blocks(...) -> RenderBlocksOutput {
    // ...
}

• popovers.rs

fn layout_cursor_popovers(...) {
    // ...
}

fn layout_hover_popovers(...) {
    // ...
}

• scrollbars.rs

fn layout_scrollbars(...) -> EditorScrollbars {
    // ...
}

fn paint_scrollbars(...) {
    // ...
}

WDYT about this structure? I guess we will also make them flat in the same folder as "element.rs" right now

[SomeoneToIgnore]

Could work, I would not use plural in module names though.