Click filenames in stack trace to open locally in editor

[yairchu]

📝 Summary

Fixes #6390

🔍 Description of Changes

• When parsing tracebacks, in addition to marimo cells replacing the traceback with a link and button, now other files are also wrapped with a clickable div element, which invokes the user's EDITOR to open the file
• marimo._server.files.OSFileSystem.open_in_editor now supports opening a file in a specific line, which the traceback uses to open the relevant line from the trace

📋 Checklist

• I have read the contributor guidelines.
• I have added tests for the changes made
  • I maintained the existing test for processing traceback HTMLs to work with the new changes
• I have run the code and verified that it works as expected.

Btw (devops)

I tried to follow the instructions according to CONTRIBUTING.md, but:

• I had to uninstall an older local version of node for things to work, otherwise node resolved to the oldest version I have which was too old?
• Couldn't get pnpm to work so had to use make fe for an >1min dev feedback cycle. (btw I'm a front-end noob so I might be missing basic things)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
marimo-docs	Ready	Preview	Comment	Sep 28, 2025 8:09am

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[yairchu]

I have read the CLA Document and I hereby sign the CLA

[Light2Dark]

I think we can add tests for the arguments generation, maybe by moving it out to a separate function.

[yairchu]

Extracted it to a separate function. Ideally it could even be in a separate package so various projects which open files in editors would share this logic. I took this snippet from my srcview package which iirc took it from git-mediate.
The main thing to test is that the editors really expect arguments this way but testing for that seems difficult.

[yairchu]

The previously failing CI tests pointed me to the additional tests I needed to maintain so can now say the changes have tests :)

Btw, make test failed for me in some tests but that also happens for me in main (so I don't think it's related to my changes)

[Light2Dark]

hi @yairchu , I think it looks good overall.

By tests, I meant some Python ones to test the [args] generation.
Feel free to implement what you can, we can also help to add stuff and merge it in.

[yairchu]

I fixed the previous CI errors and I think this time this should be good!
Does the fact that it's at "Expected — Waiting for status to be reported" for several hours mean that this time it's not failing quick and it's just the time it takes the CI to run?

[Light2Dark]

there is an error with the precommit, I created another PR for that. Thanks for the contribution!

[yairchu]

Looks like this time the 3 failing CIs aren't this PR's fault:

• pre-commit already faulty as you mentioned
• cli test / Tests CLI on windows-latest 3.12: Failed in a timeout that seems totally unrelaters
• check-schemas (openapi, packages/openapi/api.yaml, OpenAPI specification, true): Error: failed to load base spec from "main/packages/openapi/api.yaml" - the yaml was auto-generated by make fe-codegen?

[mscolnick]

@yairchu this looks great! the failing tests are likely bc you are on a fork and our GH workflows likely don't handle that well, they are just red-herring, but the main tests do pass