編集

カスタムエディター API

カスタムエディターを使用すると、拡張機能は、特定の種類のリソースに対して VS Code の標準テキストエディターの代わりに使用される、完全にカスタマイズ可能な読み書きエディターを作成できます。これらには、次のような幅広いユースケースがあります。

シェーダーや 3D モデルなどのアセットを VS Code で直接プレビューする。
Markdown や XAML などの言語用の WYSIWYG エディターを作成する。
CSV、JSON、XML などのデータファイルに代替の視覚的レンダリングを提供する。
バイナリファイルまたはテキストファイル用の完全にカスタマイズ可能な編集エクスペリエンスを構築する。

このドキュメントでは、カスタムエディター API の概要と、カスタムエディターを実装するための基本について説明します。2 種類のカスタムエディターとそれらの違い、およびユースケースに適したエディターについて説明します。次に、これらの各カスタムエディターの種類について、適切に動作するカスタムエディターを構築するための基本について説明します。

カスタムエディターは強力な新しい拡張ポイントですが、基本的なカスタムエディターを実装することは、実際にはそれほど難しくありません。それでも、初めて VS Code 拡張機能に取り組む場合は、VS Code API の基本に慣れるまで、カスタムエディターに深く入り込むのは控えることをお勧めします。カスタムエディターは、Web ビューやテキストドキュメントなど、VS Code の多くの概念に基づいて構築されているため、これらすべての新しいアイデアを同時に学習すると、少し圧倒されるかもしれません。

しかし、準備ができていて、これから構築する素晴らしいカスタムエディターについて考えているなら、始めましょう！ドキュメントに沿って、カスタムエディター API がどのように構成されているかを確認できるよう、カスタムエディター拡張機能サンプルをダウンロードしてください。

リンク

カスタムエディターサンプル

VS Code API の使用法

カスタムエディター API の基本

カスタムエディターは、特定のタイプのリソースに対して VS Code の標準テキストエディターの代わりとして表示される代替ビューです。カスタムエディターには 2 つの部分があります。ユーザーが操作するビューと、拡張機能が基になるリソースとやり取りするために使用するドキュメントモデルです。

カスタムエディターのビュー側は、Web ビューを使用して実装されます。これにより、標準の HTML、CSS、JavaScript を使用してカスタムエディターのユーザーインターフェースを構築できます。Web ビューは VS Code API に直接アクセスできませんが、メッセージをやり取りすることで拡張機能と通信できます。Web ビューとその操作のベストプラクティスの詳細については、Web ビューのドキュメントを参照してください。

カスタムエディターのもう 1 つの部分はドキュメントモデルです。このモデルは、拡張機能が操作しているリソース (ファイル) をどのように理解するかを示します。`CustomTextEditorProvider` は VS Code の標準 TextDocument をドキュメントモデルとして使用し、ファイルへのすべての変更は VS Code の標準テキスト編集 API を使用して表現されます。一方、`CustomReadonlyEditorProvider` と `CustomEditorProvider` を使用すると、独自のドキュメントモデルを提供できるため、非テキストファイル形式にも使用できます。

カスタムエディターにはリソースごとに 1 つのドキュメントモデルがありますが、このドキュメントには複数のエディターインスタンス (ビュー) が存在する場合があります。たとえば、`CustomTextEditorProvider` を持つファイルを開き、**「ビュー: エディターを分割」**コマンドを実行することを想像してください。この場合、ワークスペースにはリソースのコピーが 1 つしかないため、`TextDocument` は 1 つしかありませんが、そのリソースには 2 つの Web ビューが存在します。

`CustomEditor` 対 `CustomTextEditor`

カスタムエディターには、カスタムテキストエディターとカスタムエディターの 2 種類があります。これらの主な違いは、ドキュメントモデルをどのように定義するかです。

CustomTextEditorProvider は、VS Code の標準 TextDocument をデータモデルとして使用します。CustomTextEditor は、テキストベースのあらゆるファイルタイプに使用できます。CustomTextEditor は、VS Code がテキストファイルの操作方法をすでに知っており、保存やホットエグジットのためのファイルのバックアップなどの操作を実装できるため、実装がかなり簡単です。

一方、CustomEditorProvider を使用すると、拡張機能は独自のドキュメントモデルを持ち込みます。これは、画像などのバイナリ形式に CustomEditor を使用できることを意味しますが、保存やバックアップの実装など、より多くの責任が拡張機能にあることも意味します。プレビュー用のカスタムエディターなど、読み取り専用のカスタムエディターの場合は、この複雑さの多くをスキップできます。

どちらの種類のカスタムエディターを使用するかを決定する場合、通常は単純です。テキストベースのファイル形式を扱う場合は CustomTextEditorProvider を使用し、バイナリファイル形式の場合は CustomEditorProvider を使用します。

貢献ポイント

customEditors 貢献ポイントは、拡張機能が提供するカスタムエディターについて VS Code に伝える方法です。たとえば、VS Code は、カスタムエディターがどの種類のファイルで機能するか、および UI でカスタムエディターを識別する方法を知る必要があります。

カスタムエディター拡張機能サンプルの基本的な customEditor 貢献を次に示します。

"contributes": {
  "customEditors": [
    {
      "viewType": "catEdit.catScratch",
      "displayName": "Cat Scratch",
      "selector": [
        {
          "filenamePattern": "*.cscratch"
        }
      ],
      "priority": "default"
    }
  ]
}

customEditors は配列なので、拡張機能は複数のカスタムエディターに貢献できます。カスタムエディターのエントリ自体を分解してみましょう。

viewType - カスタムエディターの一意の識別子。

これは、VS Code が package.json 内のカスタムエディターの貢献をコード内のカスタムエディターの実装に結び付ける方法です。これはすべての拡張機能で一意である必要があるため、"preview" のような汎用的な viewType の代わりに、"viewType": "myAmazingExtension.svgPreview" のように、拡張機能に固有のものを使用するようにしてください。
displayName - VS Code の UI でカスタムエディターを識別する名前。

表示名は、**ビュー: 「別のエディターで開く」**ドロップダウンなどの VS Code UI でユーザーに表示されます。
selector - カスタムエディターがアクティブになるファイルを指定します。

selector は、1 つ以上のグロブパターンの配列です。これらのグロブパターンは、カスタムエディターが使用できるかどうかを判断するためにファイル名と照合されます。*.png のような filenamePattern は、すべての PNG ファイルでカスタムエディターを有効にします。

また、ファイル名やディレクトリ名に一致する、より具体的なパターンを作成することもできます。例えば、**/translations/*.json。
priority - (オプション) カスタムエディターが使用される時期を指定します。

priority は、リソースが開かれたときにカスタムエディターが使用されるタイミングを制御します。可能な値は次のとおりです。
- "default" - カスタムエディターの selector に一致するすべてのファイルに対してカスタムエディターを使用しようとします。特定のファイルに対して複数のカスタムエディターがある場合、ユーザーは使用したいカスタムエディターを選択する必要があります。
- "option" - デフォルトではカスタムエディターを使用しませんが、ユーザーがそれに切り替えたり、デフォルトとして設定したりできるようにします。

カスタムエディターの有効化

ユーザーがカスタムエディターのいずれかを開くと、VS Code は onCustomEditor:VIEW_TYPE アクティベーションイベントを発生させます。アクティベーション中に、拡張機能は registerCustomEditorProvider を呼び出して、予期される viewType を持つカスタムエディターを登録する必要があります。

onCustomEditor は、VS Code がカスタムエディターのインスタンスを作成する必要がある場合にのみ呼び出されることに注意することが重要です。VS Code が単に利用可能なカスタムエディターに関する情報をユーザーに表示しているだけの場合（**ビュー: 「別のエディターで開く」**コマンドなど）、拡張機能はアクティブ化されません。

カスタムテキストエディター

カスタムテキストエディターを使用すると、テキストファイル用のカスタムエディターを作成できます。これには、単純な非構造化テキストから、CSV、JSON、XML まで、あらゆるものが含まれます。カスタムテキストエディターは、VS Code の標準 TextDocument をドキュメントモデルとして使用します。

カスタムエディター拡張機能サンプルには、猫の落書きファイル（.cscratch ファイル拡張子で終わる JSON ファイル）の簡単なカスタムテキストエディターの例が含まれています。カスタムテキストエディターを実装する際の重要な部分をいくつか見てみましょう。

カスタムテキストエディターのライフサイクル

VS Code は、カスタムテキストエディターのビューコンポーネント (Web ビュー) とモデルコンポーネント (TextDocument) の両方のライフサイクルを処理します。VS Code は、新しいカスタムエディターインスタンスを作成する必要があるときに拡張機能に呼び出しを行い、ユーザーがタブを閉じるとエディターインスタンスとドキュメントモデルをクリーンアップします。

これが実際にどのように機能するかを理解するために、ユーザーがカスタムテキストエディターを開いたときと、カスタムテキストエディターを閉じたときに、拡張機能の観点から何が起こるかを見ていきましょう。

カスタムテキストエディターを開く

カスタムエディター拡張機能サンプルを使用して、ユーザーが最初に .cscratch ファイルを開いたときに何が起こるかを見てみましょう。

VS Code は onCustomEditor:catCustoms.catScratch アクティベーションイベントを発生させます。

これにより、拡張機能がまだアクティブ化されていない場合はアクティブ化されます。アクティベーション中に、拡張機能は registerCustomEditorProvider を呼び出すことで、catCustoms.catScratch 用の CustomTextEditorProvider を登録していることを確認する必要があります。
その後、VS Code は、catCustoms.catScratch 用に登録された CustomTextEditorProvider の resolveCustomTextEditor を呼び出します。

このメソッドは、開かれているリソースの TextDocument と WebviewPanel を受け取ります。拡張機能は、この Web ビューパネルの初期 HTML コンテンツを埋める必要があります。

resolveCustomTextEditor が戻ると、カスタムエディターがユーザーに表示されます。Web ビュー内に何が描画されるかは、完全に拡張機能に依存します。

カスタムエディターを分割した場合でも、カスタムエディターを開くたびに同じフローが発生します。カスタムエディターの各インスタンスには独自の WebviewPanel がありますが、複数のカスタムテキストエディターが同じリソース用である場合は、同じ TextDocument を共有します。TextDocument はリソースのモデルであり、Web ビューパネルはそのモデルのビューであると覚えておいてください。

カスタムテキストエディターを閉じる

ユーザーがカスタムテキストエディターを閉じると、VS Code はその WebviewPanel で WebviewPanel.onDidDispose イベントを発生させます。この時点で、拡張機能はそのエディターに関連付けられているリソース（イベント購読、ファイルウォッチャーなど）をクリーンアップする必要があります。

特定のリソースに対する最後のカスタムエディターが閉じられると、そのリソースの TextDocument も、他にそれを使用しているエディターがなく、他の拡張機能がそれを保持していない限り、破棄されます。TextDocument.isClosed プロパティをチェックして、TextDocument が閉じられたかどうかを確認できます。TextDocument が閉じられた後、カスタムエディターを使用して同じリソースを開くと、新しい TextDocument が開かれます。

TextDocument との変更の同期

カスタムテキストエディターは TextDocument をドキュメントモデルとして使用するため、カスタムエディターで編集が発生するたびに TextDocument を更新する責任があり、TextDocument が変更されるたびに自身を更新する責任があります。

Web ビューから TextDocument へ

カスタムテキストエディターでの編集には、ボタンのクリック、テキストの変更、項目のドラッグなど、さまざまな形式があります。ユーザーがカスタムテキストエディター内でファイル自体を編集するたびに、拡張機能は TextDocument を更新する必要があります。猫のスクラッチ拡張機能がこれを実装する方法を次に示します。

ユーザーが Web ビューで **スクラッチを追加** ボタンをクリックします。これにより、Web ビューから拡張機能にメッセージが送信されます。
拡張機能はメッセージを受信します。次に、ドキュメントの内部モデルを更新します（猫のスクラッチの例では、JSON に新しいエントリを追加するだけです）。
拡張機能は、更新された JSON をドキュメントに書き込む WorkspaceEdit を作成します。この編集は vscode.workspace.applyEdit を使用して適用されます。

ワークスペースの編集は、ドキュメントを更新するために必要な最小限の変更に留めるようにしてください。また、JSON などの言語を扱っている場合は、拡張機能がユーザーの既存の書式設定規則（スペースとタブ、インデントサイズなど）を尊重するように努める必要があることも覚えておいてください。

TextDocument から Web ビューへ

TextDocument が変更された場合、拡張機能もその Web ビューがドキュメントの新しい状態を反映していることを確認する必要があります。TextDocument は、元に戻す、やり直し、ファイルの復元などのユーザーアクションによって、または WorkspaceEdit を使用する他の拡張機能によって、または VS Code のデフォルトのテキストエディターでファイルを開くユーザーによって変更される可能性があります。猫のスクラッチ拡張機能がこれを実装する方法を次に示します。

拡張機能では、vscode.workspace.onDidChangeTextDocument イベントを購読します。このイベントは、TextDocument へのすべての変更に対して発生します（カスタムエディターが行う変更も含まれます！）。
エディターを持つドキュメントに変更が発生すると、新しいドキュメントの状態とともに Web ビューにメッセージを送信します。この Web ビューは、更新されたドキュメントをレンダリングするために自身を更新します。

カスタムエディターがトリガーするファイル編集はすべて onDidChangeTextDocument を発生させることを覚えておくことが重要です。ユーザーがウェブビューで編集を行い、それが onDidChangeTextDocument を発生させ、ウェブビューが更新され、ウェブビューが拡張機能に対して別の更新をトリガーし、それが onDidChangeTextDocument を発生させる、といった更新ループに拡張機能が陥らないようにしてください。

また、JSON や XML などの構造化言語を扱っている場合、ドキュメントが常に有効な状態であるとは限らないことを覚えておいてください。拡張機能は、エラーを適切に処理できるか、または何が問題でどうすれば修正できるかをユーザーが理解できるようにエラーメッセージを表示できる必要があります。

最後に、Web ビューの更新にコストがかかる場合は、Web ビューへの更新をデバウンスすることを検討してください。

カスタムエディター

CustomEditorProvider と CustomReadonlyEditorProvider を使用すると、バイナリファイル形式のカスタムエディターを作成できます。この API は、ファイルがユーザーにどのように表示されるか、どのように編集されるか、および拡張機能が save やその他のファイル操作にフックする方法を完全に制御できます。繰り返しますが、テキストベースのファイル形式のエディターを構築している場合は、実装がはるかに簡単なため、代わりにCustomTextEditor を使用することを強く検討してください。

カスタムエディター拡張機能サンプルには、猫の足跡の描画ファイル（.pawdraw ファイル拡張子で終わる jpeg ファイル）の簡単なカスタムバイナリエディターの例が含まれています。バイナリファイル用のカスタムエディターを構築する際に何が必要かを見てみましょう。

CustomDocument

カスタムエディターでは、拡張機能が CustomDocument インターフェースを使用して独自のドキュメントモデルを実装する責任があります。これにより、拡張機能は、カスタムエディターと対話するために必要なデータを CustomDocument に自由に保存できますが、ホットエグジットのためのファイルの保存やバックアップなどの基本的なドキュメント操作も実装する必要があります。

開かれているファイルごとに 1 つの CustomDocument があります。ユーザーは単一のリソースに対して複数のエディターを開くことができますが（現在のカスタムエディターを分割するなど）、それらのすべてのエディターは同じ CustomDocument によってバックアップされます。

カスタムエディターのライフサイクル

supportsMultipleEditorsPerDocument

デフォルトでは、VS Code は各カスタムドキュメントに対して 1 つのエディターのみを許可します。この制限により、複数のカスタムエディターインスタンスを相互に同期させることを心配する必要がないため、カスタムエディターを正しく実装することが容易になります。

ただし、拡張機能がこれをサポートできる場合は、カスタムエディターを登録する際に supportsMultipleEditorsPerDocument: true を設定することをお勧めします。これにより、同じドキュメントに対して複数のエディターインスタンスを開くことができます。これにより、カスタムエディターは VS Code の通常のテキストエディターのように動作します。

**カスタムエディターを開く** ユーザーが customEditor 貢献ポイントに一致するファイルを開くと、VS Code は onCustomEditor アクティベーションイベントを発生させ、提供されたビュータイプに対して登録されたプロバイダーを呼び出します。CustomEditorProvider には 2 つの役割があります。カスタムエディターのドキュメントを提供することと、エディター自体を提供することです。カスタムエディター拡張機能サンプルの catCustoms.pawDraw エディターで何が起こるかの順序付きリストを次に示します。

VS Code は onCustomEditor:catCustoms.pawDraw アクティベーションイベントを発生させます。

これにより、拡張機能がまだアクティブ化されていない場合はアクティブ化されます。また、アクティベーション中に、拡張機能が catCustoms.pawDraw エディター用に CustomReadonlyEditorProvider または CustomEditorProvider を登録していることを確認する必要があります。
VS Code は、catCustoms.pawDraw エディター用に登録された CustomReadonlyEditorProvider または CustomEditorProvider の openCustomDocument を呼び出します。

ここで、拡張機能はリソース URI を受け取り、そのリソースの新しい CustomDocument を返す必要があります。これは、拡張機能がそのリソースのドキュメント内部モデルを作成する時点です。これには、ディスクから初期リソース状態を読み取って解析するか、新しい CustomDocument を初期化する作業が含まれる場合があります。

拡張機能は、CustomDocument を実装する新しいクラスを作成することで、このモデルを定義できます。この初期化段階は完全に拡張機能に依存することに注意してください。VS Code は、拡張機能が CustomDocument に保存する追加情報については関心がありません。
VS Code は、ステップ 2 の CustomDocument と新しい WebviewPanel を使用して resolveCustomEditor を呼び出します。

ここで、拡張機能はカスタムエディターの初期 HTML を埋める必要があります。必要であれば、後で参照できるように、たとえばコマンド内で WebviewPanel への参照を保持することもできます。

resolveCustomEditor が戻ると、カスタムエディターがユーザーに表示されます。

ユーザーが、カスタムエディターを使用して別のエディターグループで同じリソースを開く場合（たとえば、最初のエディターを分割する場合）、拡張機能の作業は簡素化されます。この場合、VS Code は、最初のエディターが開かれたときに作成したのと同じ CustomDocument を使用して resolveCustomEditor を呼び出すだけです。

カスタムエディターを閉じる

同じリソースに対してカスタムエディターのインスタンスが 2 つ開いているとします。ユーザーがこれらのエディターを閉じると、VS Code は拡張機能に信号を送り、拡張機能はエディターに関連付けられているリソースをクリーンアップできます。

最初のエディターインスタンスが閉じられると、VS Code は閉じられたエディターの WebviewPanel で WebviewPanel.onDidDispose イベントを発生させます。この時点で、拡張機能はその特定のエディターインスタンスに関連付けられているリソースをすべてクリーンアップする必要があります。

2 番目のエディターが閉じられると、VS Code は再び WebviewPanel.onDidDispose を発生させます。しかし、今度は CustomDocument に関連付けられているすべてのエディターも閉じました。CustomDocument のエディターがなくなると、VS Code はその CustomDocument.dispose を呼び出します。拡張機能の dispose の実装は、ドキュメントに関連付けられているリソースをクリーンアップする必要があります。

その後、ユーザーがカスタムエディターを使用して同じリソースを再度開くと、新しい CustomDocument で openCustomDocument、resolveCustomEditor のすべてのフローを再度実行します。

読み取り専用カスタムエディター

以下のセクションの多くは編集をサポートするカスタムエディターにのみ適用されますが、逆説的に聞こえるかもしれませんが、多くのカスタムエディターは編集機能をまったく必要としません。たとえば、画像のプレビューを考えてみてください。または、メモリダンプの視覚的レンダリング。どちらもカスタムエディターを使用して実装できますが、どちらも編集可能である必要はありません。ここで CustomReadonlyEditorProvider が登場します。

CustomReadonlyEditorProvider を使用すると、編集をサポートしないカスタムエディターを作成できます。これらは依然としてインタラクティブですが、元に戻すや保存などの操作はサポートしていません。また、完全に編集可能なカスタムエディターと比較して、読み取り専用カスタムエディターを実装する方がはるかに簡単です。

編集可能なカスタムエディターの基本

編集可能なカスタムエディターを使用すると、元に戻す、やり直し、保存、ホットエグジットなどの標準的な VS Code 操作にフックできます。これにより、編集可能なカスタムエディターは非常に強力になりますが、適切に実装するには、編集可能なカスタムテキストエディターや読み取り専用カスタムエディターを実装するよりもはるかに複雑になります。

編集可能なカスタムエディターは CustomEditorProvider によって実装されます。このインターフェースは CustomReadonlyEditorProvider を拡張しているため、openCustomDocument や resolveCustomEditor などの基本的な操作に加えて、編集固有の一連の操作を実装する必要があります。CustomEditorProvider の編集固有の部分を見てみましょう。

編集

編集可能なカスタムドキュメントへの変更は、編集によって表現されます。編集は、テキスト変更、画像回転、リストの並べ替えなど、何でもかまいません。VS Code は編集の具体的な内容を拡張機能に完全に任せていますが、VS Code は編集が行われたときに知る必要があります。編集は、VS Code がドキュメントをダーティとしてマークする方法であり、それによって自動保存とバックアップが可能になります。

ユーザーがカスタムエディターのいずれかの Web ビューで編集を行うたびに、拡張機能は CustomEditorProvider から onDidChangeCustomDocument イベントを発生させる必要があります。onDidChangeCustomDocument イベントは、カスタムエディターの実装に応じて、CustomDocumentContentChangeEvent と CustomDocumentEditEvent の 2 つのイベントタイプを発生させることができます。

CustomDocumentContentChangeEvent

CustomDocumentContentChangeEvent は、ごく基本的な編集です。その唯一の機能は、ドキュメントが編集されたことを VS Code に通知することです。

拡張機能が onDidChangeCustomDocument から CustomDocumentContentChangeEvent を発生させると、VS Code は関連付けられたドキュメントをダーティとしてマークします。この時点では、ドキュメントがダーティでなくなる唯一の方法は、ユーザーが保存または元に戻すことです。CustomDocumentContentChangeEvent を使用するカスタムエディターは、元に戻す/やり直しをサポートしていません。

CustomDocumentEditEvent

CustomDocumentEditEvent は、元に戻す/やり直しを可能にする、より複雑な編集です。カスタムエディターは常に CustomDocumentEditEvent を使用して実装するように努め、元に戻す/やり直しを実装できない場合にのみ CustomDocumentContentChangeEvent を使用するようにフォールバックする必要があります。

CustomDocumentEditEvent には次のフィールドがあります。

document — 編集が行われた CustomDocument。
label — 作成された編集の種類を説明するオプションのテキスト（例：「切り抜き」、「挿入」、...）
undo — 編集を取り消す必要があるときに VS Code によって呼び出される関数。
redo — 編集をやり直す必要があるときに VS Code によって呼び出される関数。

拡張機能が onDidChangeCustomDocument から CustomDocumentEditEvent を発生させると、VS Code は関連付けられたドキュメントをダーティとしてマークします。ドキュメントをダーティでない状態にするには、ユーザーはドキュメントを保存または元に戻すか、ドキュメントの最後に保存された状態に戻すために元に戻す/やり直しを行うことができます。

エディターの undo メソッドと redo メソッドは、特定の編集を取り消すか再適用する必要があるときに VS Code によって呼び出されます。VS Code は編集の内部スタックを維持するため、拡張機能が 3 つの編集で onDidChangeCustomDocument を発生させた場合、それらを a、b、c と呼びましょう。

onDidChangeCustomDocument(a);
onDidChangeCustomDocument(b);
onDidChangeCustomDocument(c);

次のユーザーアクションのシーケンスにより、これらの呼び出しが発生します。

undo — c.undo()
undo — b.undo()
redo — b.redo()
redo — c.redo()
redo — no op, no more edits

元に戻す/やり直しを実装するには、拡張機能は関連するカスタムドキュメントの内部状態を更新し、ドキュメントの新しい状態を反映するようにドキュメントに関連するすべての Web ビューを更新する必要があります。単一のリソースに対して複数の Web ビューが存在する可能性があることを覚えておいてください。これらは常に同じドキュメントデータを表示する必要があります。たとえば、画像エディターの複数のインスタンスは常に同じピクセルデータを表示する必要がありますが、各エディターインスタンスに独自のズームレベルと UI 状態を持たせることは可能です。

保存

ユーザーがカスタムエディターを保存すると、拡張機能は保存されたリソースを現在の状態でディスクに書き込む責任があります。カスタムエディターがこれをどのように行うかは、主に拡張機能の CustomDocument の種類と、拡張機能が内部で編集をどのように追跡するかによって異なります。

保存の最初のステップは、ディスクに書き込むデータストリームを取得することです。これに対する一般的なアプローチには次のものがあります。

リソースの状態を追跡し、迅速にシリアル化できるようにする。

たとえば、基本的な画像エディターはピクセルデータのバッファーを維持する場合があります。
前回の保存以降の編集をリプレイして、新しいファイルを生成する。

たとえば、より効率的な画像エディターは、前回の保存以降の編集（crop、rotate、scale など）を追跡する場合があります。保存時に、これらの編集をファイルの最後に保存された状態に適用して、新しいファイルを生成します。
ファイルを保存するためのカスタムエディターの WebviewPanel にファイルデータを要求する。

ただし、カスタムエディターは表示されていない場合でも保存できることに注意してください。このため、拡張機能の save の実装は WebviewPanel に依存しないことをお勧めします。これが不可能な場合は、WebviewPanelOptions.retainContextWhenHidden 設定を使用して、ウェブビューが非表示のままでもアクティブな状態を維持できます。retainContextWhenHidden はかなりのメモリオーバーヘッドがあるため、使用には注意してください。

リソースのデータを取得した後、通常はワークスペース FS API を使用してディスクに書き込みます。FS API は UInt8Array のデータを受け取り、バイナリファイルとテキストベースの両方のファイルを書き込むことができます。バイナリファイルデータの場合は、バイナリデータを UInt8Array に入れるだけです。テキストファイルデータの場合は、Buffer を使用して文字列を UInt8Array に変換します。

const writeData = Buffer.from('my text data', 'utf8');
vscode.workspace.fs.writeFile(fileUri, writeData);

次のステップ

VS Code の拡張機能について詳しく知りたい場合は、次のトピックを試してください。

拡張機能 API - VS Code 拡張機能 API の全容を学びましょう。
拡張機能の機能 - VS Code を拡張する他の方法を見てみましょう。

10/09/2025