SublimeKSPとVisual Studio Code KSP拡張機能についての違い

指の捻挫が中々治らない あーる(@rkoubou_jp) です。新入社員の人は最初の金曜日でしょうか。初週でどのように会社と呼ばれるものが皆さんの目に写っているのかを知ってみたい今日このごろです。

閑話休題。

公開中のVSCode拡張機能がある程度安定してきたので、一度SublimeKSPとの比較をまとめてみます。

目次

VSCodeのKSP拡張機能を作成したきっかけ

実のところ、初めから「KSP拡張機能を作るぞ」というわけではありませんでした。
メインのエディタをVSCodeに乗り換えた頃、操作方法を覚えていくうちに

  • VSCodeは自分でプログラムを書いて拡張機能を組み込める
  • 主に TypeSript / JavaScript、Node を使う
  • 拡張機能をMSのマーケットプレイスで公開もできる
  • コンパイラの作成の復習

というのがきっかけでTypeScriptの学習、拡張機能の習作も兼ねて始めました。

サンプルレベルの習作を重ねていき、おおよその全体像がぼんやりと見えてきたので
一定以上・公開できるレベルの物を１つ作ってみようと思い、KSP を思い浮かべました。

そして、後で自分がKSPを書く時になったら楽にエディットできる環境を作っておきたいと思ったわけです。

MSマーケットプレイスにまだ誰も公開していなかった

大抵の言語は公開されていたのでKSPもあるだろう、と思ったら意外にも無かったのです。

既にSublimeKSPがある種覇権を取っているようなものですので、特に需要は無かったと推測されます。

SublimeKSPのここが辛くね？→じゃあ作りますか

ここが一番つらい

文法エラー時にポップアップダイアログが出る
↓
スクリプトを直す
↓
また文法エラーがあったら再びポップアップダイアログが出る
↓
スクリプトを直す
↓
（以下略）

8行目か？5行目か？どっちだ？つまりなんでエラー？

VSCodeの拡張機能として公開されていない、ググっても誰も作っている様子もない。

ということで、「無いものを待っていても来ないので作ろう」となりました。

いちいちポップアップダイアログを出さずにリアルタイムに提示する。純粋に状況が分かりやすい。はず。

元々、自分は（規模の大小・機能の精度を抜きに）世にまだ存在しない物を作るのが好きです。

それが今回のKSPに繋がっています。

文法解析機能

この機能については、VSCode拡張機能とは独立したコンパイラを作成しています。
利用される方から見るとVSCode拡張機能の一機能と見えるかと思いますが、全く別の別プログラムを書いて、VScode拡張機能内部で連携をさせています。

SublimeKSPとの比較

前置きが長くなりました。比較です。

項目 SublimeKSP KSP for VSCode
シンタックスハイライト ○ ○
入力補完 ○ ○
リファクタリング(名前変更) – ○
スニペット – ○
変数、UI変数のコールバック、 ユーザー関数宣言箇所へのジャンプ – ○
文法・チェックのタイミング ユーザー操作 リアルタイム
文法エラー等が検出された場合 ポップアップダイアログ表示、 その時点で文法チェックが停止 画面下の問題ビューに検出可能な限り継続、 該当行にジャンプ可能
静的な警告を検知 – 文法チェック時に実施 ＊1
オブファスケート（難読化） ○ ○ ＊2
オプティマイズ ○ ○ ＊3
独自の拡張構文 ○ –
将来のバージョンで追加された変数やコマンドに対する対応 プログラム改修待ち プログラム改修無しでテキストで追加可能 ＊4

トータルでの機能性

  • SublimeKSP > VSCode KSP

やはり「拡張構文」をサポートしている点については、SublimeKSPが与える恩恵は大きい。

また、イニシアチブを持っているので、安定性や情報量がVI Controlでの情報交換が活発である。

ただしVSCode KSPにしか搭載されていない物も多くあるので、エディタの好みや信頼性・知名度などで個々人で見解が別れると考えている。

*1 静的な警告を検知

VSCode KSP では、以下のケースのチェックも行い適宜エラーや警告を出す（一部strictモードがオンの場合に限る）
Sublimeプラグインでは若干厳密ではない。この点は VSCode KSP が勝っていると思っている。

  • on init コールバック内で有効コード行数が8000行近くに達するとKONTAKTがスタックオーバーフローを引き起こすバグがあるという情報を頂き、計測を行っている。
  • 配列変数宣言時に要素数が 0 未満、または上限である 32768 を超える場合
    • →エラーとして扱う
  • 配列変数アクセス時、添え字チェック（要素インデックスが0未満、または上限である 32768 を超えることが確定している場合）
    • →エラーとして扱う
  • select〜case 内の case xx to yy において xxとyyが常に同じ値である場合
    • →警告として扱う
  • 変数名が数字から始まる場合（KSPはOKでも、一般的なスクリプト言語やプログラミング言語ではNG）
    • →警告として扱う
  • on init 内でコール不可能なコマンドのチェック
    • →エラーとして扱う。実際にKONTAKT上で検証、許可されていないコマンドはデータ化して管理している。
  • UI変数の初期化パラメーターの型チェック
    • →型が一致しない場合はエラーとして扱う。

*2 オブファスケート（難読化）

SublimeKSPで個別にオブファスケートのレベルを選択できるが、VSCodeでは固定。

SublimeKSPのオプションで全てにチェックが入っているバージョンに相当する。

SublimeKSPとの唯一の違いは、「ユーザー関数のインライン展開」を行うかどうかをオプションで備えている。

call コマンド自体のコールコスト（負荷）が思っていた以上にあることが分かったため、全部展開できれば高速化の見込みがある。

（call コマンド自体のコールコスト: 50 microseconds/call）

*3 オプティマイズ

文字列の結合。

VSCode KSP のオブファスケーターでは、静的に & 演算子で連結される結果が常に同じである場合、１つの文字列として連結を行う。これにより、 & 演算子による連結負荷を軽減できる。

例：
message( "Hello " & 2018 & "! Next Year is " & 2019 & "!" )
↓
message( "Hello 2018! Next Year is 2019!" )

リテラル値であるが、const宣言している変数でも同様に連結を行う。

例：
on init
    declare const $THIS_YEAR := 2018
    declare const $NEXT_YEAR := $THIS_YEAR + 1
    message( "Hello " & $THIS_YEAR & "! Next Year is " & $NEXT_YEAR & "!" )
end on
↓
on init
    message( "Hello 2018! Next Year is 2019!" )
end on

*4 将来のバージョンで追加された変数やコマンドに対する対応

VSCode KSPでは文法解析機能に限り再コンパイル、再ビルドが不要である。
最悪ユーザー自身が ~/.vscode/extention/r-koubou-ksp-###/kspparser/data/ 以下のテキストファイルで直接追記できる

＊シンタックスハイライト対応の場合は、拡張機能内の所定ファイルに(*.json)に加える必要がある

さいごに

エクステンションIDの変更でインストール総数が1度リセットしていますが
合算で1500を超えました。想定以上にインストールされているんだな、と改めて実感しています。

また、不具合のフィードバックを頂いたお陰で、コンパイラのかなり精度が向上しました。

この場を借りて御礼申し上げます。

直近で嬉しかったことは VSCode のプロジェクト主要プログラムマネージャー（Principal Program Manager）のMicrosoftのChris Dias氏にTwitterでリツイートを頂き、知ってもらえたこと、プロジェクトのWatching にも Microsoft UK のSenior Programmer
の人がいることです。特別何かがあったわけではないですが嬉しいですね。

SublimeKSPの方が先に世に出ていますし、拡張構文や、KSP関連のエディタではイニシアチブを持っています。

VSCode KSPはクローンを目指しているわけではなく、VSCodeの強力な機能を利用し、SublimeKSPでは実現できない点を以てスクリプトの編集効率が上がればと思い、日々アップデートをしています。

ただ、動作不安定な部分もあるかもしれません。
ご連絡を頂ければ対応しますし、安定しているSublimeKSPに乗り換えてもらうのも１つの選択だと思います。

Tags