update the documentSelector to apply to inmemory python documents#1637
Closed
austin3dickey wants to merge 1 commit intofacebook:mainfrom
Closed
update the documentSelector to apply to inmemory python documents#1637austin3dickey wants to merge 1 commit intofacebook:mainfrom
inmemory python documents#1637austin3dickey wants to merge 1 commit intofacebook:mainfrom
Conversation
Contributor
yangdanny97
approved these changes
Nov 21, 2025
Contributor
yangdanny97
left a comment
yangdanny97
left a comment
There was a problem hiding this comment.
Review automatically exported from Phabricator review in Meta.
Contributor
|
@austin3dickey Thank you for the PR! This looks good, and we're merging it internally now. |
Contributor
5 tasks
meta-codesync bot
pushed a commit
that referenced
this pull request
Apr 15, 2026
Summary: I didn't make an issue for this, but I can first if you'd like! One-line change to fix `inmemory` documents (e.g. the [Positron](https://positron.posit.co/blog/posts/2026-03-31-python-type-checkers/) Console) failing to be registered with the server on Windows. This is a follow-up to #1637, which added `inmemory` to the extension's `documentSelector`. That change works on Mac/Linux but not on Windows because the LSP server's `did_open` rejects `inmemory` URIs on that platform. ### Root cause When `did_open` receives an `inmemory` URI like `inmemory:/repl-python-<uuid>`, it calls `Url::to_file_path()`. That method doesn't check the URI scheme, it just converts path segments into a platform path. On Mac/Linux this happens to succeed (producing `/repl-python-<uuid>`), but on Windows it fails because `file_url_segments_to_pathbuf_windows` requires the first path segment to be a drive letter like `C:`. After `to_file_path()` fails, the fallback in `did_open` only accepts `untitled`, so `inmemory` documents are silently rejected on Windows and never registered. But the fallback should work for both schemes. ### Fix Extend the scheme check in `did_open` to also accept `inmemory`, routing it through the `UnsavedFileTracker`. This makes the behavior consistent across platforms instead of relying on `to_file_path()` accidentally succeeding on Unix. I added tests for semantic tokens and completions on `inmemory` documents, mirroring the existing `untitled` tests, so regressions here will be caught going forward. Pull Request resolved: #3137 Test Plan: - [x] Existing `unsaved_file` tests still pass - [x] New tests pass - [x] Verified completions and semantic highlighting work in Positron Console on Windows - [x] Verified they still work in Positron Console on Mac - [x] Ran `test.py` (no changes) Reviewed By: kinto0 Differential Revision: D100894098 Pulled By: rchen152 fbshipit-source-id: 2a30b889559d0b9de1d6ed642cd53505139f7ca5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi! 👋 This PR adds an entry to the language client
documentSelectorso that Pyrefly LSP features apply to Python documents with the schemainmemory.I work on the Code - OSS fork Positron. We've been impressed by the features and maturity of this project, and since Positron is intended to be a batteries-included IDE, we are going to bundle the Pyrefly extension with new releases, instead of relying fully on our bespoke Jedi LSP like in the past.
One of the features of Positron is its Console, which is where users can run interactive temporary code. We intend to have the same LSP experience in the Console as in document editing. The text in our Console uses the
inmemoryschema, which is similar to how other in-memory text editor models in extensions work. This is important so we don't trigger file-saving behavior or other things that are associated with files on disk.I think it would make sense for Pyrefly to work in these in-memory Python situations, both for the Positron Console and otherwise.