Skip to content

Let an extension own a file type - #83

Merged
Seungpyo1007 merged 1 commit into
developfrom
feature/custom-text-editors
Aug 11, 2026
Merged

Let an extension own a file type#83
Seungpyo1007 merged 1 commit into
developfrom
feature/custom-text-editors

Conversation

@Seungpyo1007

Copy link
Copy Markdown
Member

The remaining half of track C-3 from the 0.3.0 plan.

An extension can own a file type

contributes.customEditors declares which patterns a viewType claims; registerCustomEditorProvider supplies the implementation. Both have to be present — a declaration alone falls back to the text editor, which is better than a blank pane when the extension has not activated yet. That pairing is src/ext/customEditors.ts, pure, with 18 tests.

The document stays a normal TextDocument, so an extension edits through WorkspaceEdit and the change goes via the model — Ctrl+Z still works and the save baseline stays honest.

CustomEditorProvider — the binary kind that owns its own bytes, save and backup — is still not supported, and registering one throws at registration naming what is missing. Registering it silently would open that file type to a blank pane.

Two defects found while building it

  • .draw files have no model. preload only creates models for TS-like files, and a file claimed by a custom editor never gets a Monaco pane either, so nothing created one. The extension received null and died on its first document.getText(). The document is now read and created on demand.
  • The iframe had no acquireVsCodeApi. The extension's own script died on its first line and the webview could not talk back at all. It now goes through the same bridge the sidebar webviews use.

README corrected

It claimed the shim has no custom editors and that WorkspaceEdit cannot create, delete or rename files — the latter has been false since #71, and debug observation since #79. Rewritten to what is actually true, with the two genuinely missing pieces named.

Verification

Real app with a probe extension owning *.draw, 5/5: the file opens in the extension's iframe rather than Monaco, resolveCustomTextEditor is called, the document text reaches the extension ("SHAPES: circle, square\n"), a message from the webview arrives at the extension, and a file it does not claim still opens as text.

1133 unit tests passing (18 new). npm run typecheck and npm run build clean.

contributes.customEditors 선언 + registerCustomEditorProvider 구현이 둘 다
있어야 그 파일이 그 편집기로 열린다. 선언만 있으면 텍스트로 연다 — 확장이
아직 안 떴을 때 빈 화면 띄우는 것보다 낫다.

문서는 평범한 TextDocument 라 확장이 고칠 때 WorkspaceEdit 을 쓴다. 모델을
거치니까 Ctrl+Z 도 되고 저장 기준선도 안 어긋난다.

바이너리를 직접 들고 저장·백업까지 하는 CustomEditorProvider 는 아직 없음.
resolveCustomTextEditor 가 없으면 등록 시점에 던진다. 조용히 등록해두면 그
파일이 빈 화면으로 열린다.

만들면서 나온 것 둘.
- .draw 같은 파일은 모델이 없다. preload 는 TS 계열만 세우고 커스텀 편집기가
  맡으면 Monaco 페인도 안 뜨니까. 확장에 null 이 가서 document.getText() 가
  첫 줄에서 던졌다. 없으면 읽어서 세우게 함.
- iframe 에 acquireVsCodeApi 를 안 넣어서 웹뷰 스크립트가 죽었다. 사이드바
  웹뷰가 쓰는 주입기를 그대로 쓴다.

README 도 실제 상태로. WorkspaceEdit 파일 조작과 디버그 관찰은 이미 되는데
"없다" 고 적혀 있었다.
@Seungpyo1007 Seungpyo1007 added this to the v0.3 (2026-09-30) milestone Aug 11, 2026
@Seungpyo1007 Seungpyo1007 added the enhancement New feature or request label Aug 11, 2026
@Seungpyo1007 Seungpyo1007 self-assigned this Aug 11, 2026
@Seungpyo1007
Seungpyo1007 merged commit 8eb30db into develop Aug 11, 2026
1 check passed
@Seungpyo1007
Seungpyo1007 deleted the feature/custom-text-editors branch August 11, 2026 04:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant