| |
こんにちは。秀丸愛用者の「でるもんた・いいじま」です。
> コーディングする際に、秀丸エディタ標準機能として、
> スニペット機能実装を切に要望します。
>
> 欲を言うとVisualCODEと同様なユーザー定義スニペットが
> 書ければ嬉しいです。
> 現在はVSCODEといったり来たりしています。
「スニペット」というキーワードを寡聞にして知らなかったので、
検索してみました。確かに、そういう機能自体はコーディングの際に
便利だとは思います。
<余談>
私自身、ごくたまにXMLを書く際などには、
<?xml version="1.0" charset="Shift_JIS" ?>
と書いてしまってパーサーが不親切なエラーを出したり（ここでは
charsetではなくencodingと書くのが正しい；メールヘッダやHTTP
レスポンスヘッダなどにMIMEタイプを書く際にはcharsetなんです
が）、CDATAセクションの開始にはどんな文字をどの順序で書くん
だっけと悩んだりしています。
で、日本語環境なら「IMEに単語登録しておく」という荒業も使える
のですが、これはこれで文字数に制限があったり、単語の中に改行を
入れることができなかったり、半角文字にしないといけない部分が
設定次第では全角に化けてしまったり、色々と問題がありますよね。
それにそもそも、IMEの単語登録機能を日常的に使う言語なんて、
私自身が知っているものとしては日本語の他には中国語くらいしか
ありませんので、日常の環境が日本語・中国語でない人の場合、単語
登録とは全く独立なスニペット機能の需要があるのは理解できます。
</余談>
☆ ☆ ☆
さて、とはいっても、スニペット機能を秀丸の標準機能として組み込む
べきかというと、何となくですが、現時点では秀丸の基本思想に反する
ような気がしています。
というのも、秀丸にしてもEmacsにしても、あるいは昔ならVZエディタ
あたりもそうですが、「マクロで問題なく実装できる機能はできるだけ
マクロで実装する」というのが、昔からのテキストエディタの基本的な
哲学だからです。マクロで実装することにより、デフォルトの挙動に
不満がある場合に、あるいは新しい文法に対応する必要に迫られた場合
に、長時間かけてバイナリを再コンパイルする必要がなくなりますし、
また、コンパイラ言語にありがちな配列境界超過やヌルポインタなどの
セキュリティホールを発生させる危険性も減ります。ちょっと気に
なった機能を追加したり、普段とは少しだけ条件の違う別環境に細かい
設定を持ち込んだりといった作業も、バイナリ全体を再コンパイルする
よりはマクロにしたほうがよっぽど簡単です。
逆に、VS Codeあたりが標準で山のように機能を組み込んでいるのは、
小さいころからテキストエディタよりもWordあたりに慣れ親しんで
きた人たちが今の時代に即席プログラマとして大量に求められていて、
それでいて、書くべきプログラムのほうは文法や規則が急速に複雑化
してきていて…という事情があるのかな、と思っています。IT業界の
底辺では、15年くらい前からこのへんの状況の悪い側面が色々と出て
きています。
すみません、話が少し逸れました。スニペットに話を戻します。
スニペット機能は現状では、「どのエディタにも同じ機能がもれなく
ついてくる」「こういう操作でこういう挙動になるのがユーザのほぼ
全員の共通認識」「この製品が定番」といえるものはないと思います。
たとえば、エディタに多数登録されている文例の中から目的のものを
選び出すときに、カーソル位置周辺の文面を参照するのかしないのか、
文例を選択する操作は一覧表の中からマウスクリックか、キーボード
でのツリー操作か、それとも文例に付けられたタイトル（またはその
先頭の数文字なり略号なり）をタイプするのか。たったこれだけの
ことでも、実際に作ろうとなると無限の可能性があります。
なので、スニペットに関しては今後しばらくは色々な人が色々な改良を
試みていって、今から10年後くらいに、落ちつくべきところに落ち着く
のではないかと個人的には予想しています。
そういう状況なので、たとえば現時点でのVS Codeの機能をそのまま
秀丸に移植したとしても、VS Codeの次のバージョンで、今までとは
大幅に操作性の違うものが新たに提供されるかもしれません。逆に、
秀丸は昔から「前のバージョンとの互換性」を極端なまでに重視して
いますから、いったん何かをハードコードしてしまったら、将来的に
なかなか変更ができなくなります。
なので、現時点ではやはりマクロで実装すべきです。
☆ ☆ ☆
さらに、Microsoftの巨大組織とサイトー企画さんの少人数体制とを
比較すると、同じ問題に挑む場合でも、完全に同じアプローチで行く、
つまり秀丸側がMicrosoftのように自社内ですべてを丸抱えしてしまう、
という方法には根本的に無理があります。
秀丸側としては、もし高機能なものを作りたければ、
0.大前提として、どこか1箇所の拠点ですべてを開発するのでは
なく、コミュニティ開発型のオープンソース態勢とする。
1.スニペット機能のエンジンは、基本的にはマクロで実装する。
必要に応じてWSHなども活用するが、Windowsにデフォルトで
入っていない機能をエンジン開発者以外の利用者に要求する
のは極力避ける。
2.スニペットの文面は別途テキストファイルに書いておき（そう
すれば自動的に、ユーザー定義スニペットを利用したいという
要望も満たされますね）、具体的なコンテンツは既存のフリー
の辞書から引っ張ってくる。
3.秀丸の機能の制約によってどうしても解決困難な問題が生じた
場合には、その点に絞ってサイトー企画さんにお願いする。
4.他のエディタのコミュニティとも連携し、既にどこかの製品
向けに実装されていて他の製品に転用可能なコードは相互に
提供しあう。
という方針でいくしかないと思います。
現状では、秀丸のユーザさんはそれぞれの人がそれぞれの作業に必要な
最小限の機能だけのマクロをそれぞれ別々に作っている、という状況
だと思います。結局、ほとんどの人にとってはそれで足りてしまうん
ですよね。
逆に、VS Codeのほうは「少しでも需要がある機能は、有り余っている
人的リソースにモノを言わせて（場合によっては、新人プログラマの
練習作品として）何でも実装する」という体制でしょうから機能は
盛り沢山でしょうけど、それだけたくさんの機能のうち、全体の25%
でも毎日のように活用しているというユーザは絶対にいないはずです。
私自身はVS Codeは使っていませんが、WordやExcelあたりでふだん
使う機能にしても、製品が提供している機能のうちの1%にも満たない
はずです。
なので、VS Codeと同等の盛り沢山のものをこれから作ろうとしても、
まず最初に「どれだけ需要があるのか？」「投下した資本は回収
できるのか？」という問題が出てきます。VS Codeでこういう盛り
沢山の実装が可能なのは、ユーザも開発者も大人数な上に、投入
した人件費がもし売上に結び付かなくても担当プログラマの訓練と
しては十分な効果が上がる仕組みになっていて、極端な話、何を
作っても無駄にはならない、という事情があります。
☆ ☆ ☆
あるいは、無駄な機能は削って軽量にしてくれ、という需要も確実に
存在します。これは昔から汎用の（＝特定のプログラム言語に特化
していない）テキストエディタに求められている需要の一つですし、
UNIX系の環境では「Emacs vs vi」論争の大きな論点の一つですし、
現状、Windows上では秀丸がそういう需要の大きな受け皿の一つに
なっているということも忘れないでください。
…と、ここまで書いてきたんですけど、秀丸の指向性があくまで汎用
テキストエディタなのに対して、VS Codeは最初からテキストエディタ
ではなく多言語IDEとして開発された製品なのかな、と思っています。
場合によっては将来、VS CodeにはHTML・XML・LaTeX・JSONなどとい
ったデータをWYSIWYGで編集する機能が実装されても全く不思議では
ありません。
それにMicrosoftとしては、どんどん機能を追加して環境をを重くして
いき、PCの買い替え需要を喚起したほうが、WindowsやOfficeなどの
ロイヤリティ収入が増えて儲かる、という事情もあります。その点
でも、「軽量指向」の秀丸と「重量化志向」のVS Codeとでは方向性
が真逆です。
☆ ☆ ☆
というわけで、かなり大風呂敷を広げてしまいましたが、最終的な
結論としては「VS Codeと比較すること自体に無理があるので、まず、
自分が欲しいと思う最低限のものを自分で作ってみよ」ということに
なると思います。極端な話、そのレベルのことが（多少は他人の力を
借りるにしても）自力でできない人には、他人様からお金を戴いて
プログラムを書くのはご遠慮願いたいと思っています。
とりあえず、既にマクロライブラリにスニペットのマクロがあるとの
ことですので、まずはそれをいじってみてはいかがでしょうか。
あとは、目的のプログラミング言語に合わせたフリーの辞書がないか
どうか探してみることからですね。
以上、老害のような回答で申し訳ありませんが、「自分でできそうな
ことは積極的に自分でやってみる」ということはいつの時代でも重要
だと思いますし、質問者さまなら十分にそれが可能だと思います。
|
|