Fix "Untitled Document {N}" numbering progression when another doc includes that substring

[Keavon]

There was a bug with the choice of numbering the next "Untitled Document {N}". If documents are: "Untitled Document", "Untitled Document 2", "My Untitled Document 3", the third one shouldn't count because it's just a user-chosen name with a substring of "Untitled Document {N}". This fixes it so the next proposed number becomes "Untitled Document 3" instead of 4. It also simplifies the code.

[gemini-code-assist]

Code Review

This pull request simplifies the logic in generate_new_document_name for finding the lowest unused document number by utilizing a HashSet and strip_prefix. However, a bug was identified where document names with non-numeric suffixes (such as "Untitled Document copy") will fail to parse and incorrectly default to 1, thereby blocking the base name "Untitled Document" from being reused. A code suggestion is provided to correctly handle these cases by only mapping to 1 when the suffix is empty and ignoring other parsing failures.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[cubic-dev-ai]

1 issue found across 1 file

Confidence score: 4/5

• In editor/src/messages/portfolio/portfolio_message_handler.rs, the rest.trim().parse::<usize>().unwrap_or(1) fallback makes invalid suffixes collapse to document number 1, so malformed names can be treated the same as "Untitled Document" and trigger false collision handling or unexpected renaming behavior; handle parse failures explicitly (e.g., reject invalid suffixes or branch to a non-colliding path) before merging.

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>