Cursor adds a “Preview | Markdown” toggle to the tab bar for .md files. When a CustomTextEditorProvider extension registers as the default editor for markdown files, this toggle conflicts with the extension’s own mode switching — clicking Cursor’s toggle takes the user out of the custom editor entirely, switching to Cursor’s built-in markdown preview or raw text editor.
There’s no way for an extension to signal that it handles its own preview/raw toggling and doesn’t want Cursor’s tab bar toggle.
Proposed solution
Expose a way for CustomTextEditorProvider extensions to opt out of the tab bar toggle. Some options:
A when clause context — e.g., suppress the toggle when activeCustomEditorId == ‘myExtension.viewType’
A capability flag in the customEditors contribution point — e.g., “supportsOwnModeToggle”: true
A command — cursor.hideMarkdownToggle that extensions can call when their editor is active
Context
This affects Human Markdown, a WYSIWYG markdown editor that registers as a CustomTextEditorProvider with priority: “default” for *.md files. It has its own rich text / raw source toggle. We currently show a banner warning Cursor users not to use Cursor’s toggle, but that’s a poor UX workaround.
Hey, thanks for the detailed feature request. We don’t often see requests with this level of thought, especially from an extension author.
Confirmed: CustomTextEditorProvider currently has no way to hide the built-in Preview | Markdown toggle. The toggle shows up for all .md files, and right now it doesn’t account for a custom editor being active for the file.
The request makes sense. I’m leaving the thread open so it can gather community upvotes, that helps us with prioritization. If you have a preferred option out of the three (when clause / capability flag in customEditors / command), let us know which one works best from the extension API side, that’s a helpful signal.
I can’t share an ETA yet. If there’s an update, I’ll post it here.
Of the three options, a capability flag in the customEditors contribution point is my strong preference; something like “supportsOwnModeToggle”: true in package.json.
Here are my thoughts:
Declarative and static: Cursor can read it at activation time without waiting for the extension to run a command or set context. No race between the toggle appearing and the extension hiding it.
Zero runtime cost: no context key listeners, no command registration just to suppress UI chrome.
Scoped to the right level: it’s per-editor-type, not per-file or per-window. If someone has a custom markdown editor and a custom CSV editor in the same session, each can declare independently.
The when clause approach would work, but puts the burden on every extension to manage context keys correctly (set on focus, clear on blur, handle multiple editor groups). The command approach has the same lifecycle complexity plus a flash-of-toggle on activation.
One edge case worth considering: if the user manually switches back to Cursor’s built-in text editor via “Reopen With,” the toggle should reappear since the custom editor is no longer active. The capability flag naturally handles this since it’s tied to the editor type, not the file type.
Happy to test a preview build if that’s useful when the time comes.
Great breakdown, thanks. The arguments for a capability flag are solid, especially the declarative, static approach (no race between the toggle showing up and getting hidden) and tying it to the editor type instead of the file. The edge case with Reopen With is also a good call. Since the flag is tied to the editor type, it solves that case naturally.
I’m going to leave the thread open for now so it can get more upvotes from the community, since that affects prioritization. I can’t share an ETA, but if there’s an update, I’ll post it here.