KENCH

>MAX_PATH(260文字) を超えるパス長を扱いたいかどうか 扱いたい場面はしばしば生まれますが、この場面が発生したときには、既に他のファイル処理系もグダグダになる事も経験済なので、世の中がみんなロングなのを扱いだしたときに考えるでもいいのかも（しばらく放置）。そのころには何か新しいアーキテクチャうまれてるかもと。

落書き これがよく起きるシチュエーション、 ファイル共有サーバでドライブマッピングしたところにバックアップ取ったWebアプリプロジェクト(Eclipseプロジェクトとかnode.jsとか)が、ドライブマッピングなしだともう手が届かない。。。 node.jsやたら深くなる。。。

既存の「外部コマンド実行」は、出力結果をエディタ内に取り込むという「要件」があるかと思います。 「ターミナル」はコンソールを内部で取り込んでコマンドを実行するということかと思いますが、 後者の要件は私はCMD.EXE他を単独で実行することで実現しています（代替え可能） もし、コンソールをテキストエディタの内部で持つ場合、出力結果をうまく取り込めるとか、編集中のテキストをうまくコンソールへ反映させるような機能があると、内部にもつ意義があるかなと思います。 内部で持つ場合には、なるべく既存のexeが肥大化しない仕組みがあるとか、一からカーソル移動等を実装しなくてもよい（なるべく外部モジュールへ任せられる）方向に倒したいなとおもいます。 そういう仕組みがあればですが。 ターミナルをゼロからくみ上げるのは結構骨が折れそうなので。

バージョン番号の上げ方は決まったルールはないような気がします。 ここで決めてしまうのもいいかもですね。 バージョン：ソフト的に大きな変更がある場合（Ansi->Unicodeとか32Bit->64bitでもここあげる？) リビジョン：新機能等の追加等 ３桁目（なんていうの？）：ソフトによりますが、この桁でバグフィックス対応ほか軽微な修正、パッチ的な修正。 ４桁目（なんていうの？）：パッケージングしなおし、プログラム以外の付帯物の修正追加 こんな感じですかね。 で、次をどうするかですが、OSSそのものに対して確かに何か大きなインパクトがあるわけではないので、@berryzplus さんの言われることは激しく同意なのですが、GitHub移行後の初めてのパッケージングはソフト本体は延長線上であるものの新しいアーキテクチャでこしらえた新しいパッケージであることを外部に意思表示するいみではリビジョンをあげるのもいいのかなと。 @m-tmatma さん言われるように何か目玉な機能はほしい気もしますけれども。 もう一つの味方としては、切れ目なくこれからも修正しつづけてるんですよってことで、単に４桁目か３桁目だけ上げた版をさらりとリリースするって考え方もありますね。 すいません。どっちやねんって感じになりました。

@kobake さん、おそらく、「64bit版もあるよっていってるだけ」で正式にリリースしたってことはいってないのかなと。 聞屋さんは事実を嘘ではない範囲で（たまに嘘もあるけど）さもどうとでも取れるような書き方はよくします。

>Google Formsのアンケートとかで利用者の声を集めて見るのも良いかもしれませんね・・・ すごい今時っぽいですね。その発想はなかったです。

純粋な機能要求だと、閉じタグ(言語依存だと、{[enter]で、}が下の行に挿入されるとか、< pre >[enter]でが挿入されるとか、try {[enter]で }catch{ }って挿入されるとか)自動挿入かなぁ。。。と呟やいてみる。 すいません、話がそれそうなのでこのへんで。

>SakuraDown って誰がメンテしているのかって誰か分かりますか。 http://sakura.qp.land.to/?Install%2FSakuraDown ここ見ると最後に修正したのは、 >.NET Ver1.3.x alphaがダウンロードできないため、Ver1.2f-18でダウンロードできるように対応しました。 -- novice? 2017-08-22 (火) 02:40:39 noviceさんですかね。 ソースも同封されてるので誰でも直せるって感じなのかもしれませんね。 確かに私でも直せそうです。

Wikiのところにバイナリー公開されていないようですが、ヒストリーに、 >.NET Ver1.3.x alpha　VB2005.NET移植版。sakura2.x版のみ提供。 っての記載がありますね。はて。。。？？？

いわゆる「回帰テスト」ってことですかね。 いわゆるJTest的なことをインタフェース（UI、コマンドライン）に対して総当り的に行うのが理想なのかもしれないけど、クリック位置とか、再描画後の画面が正しく描画されているかとか、 UIに対して導入するのは難しいのかなと。 であるならば、各ファンクション（出来たら全ファンクション）のカバレージが１００％になるように、テストパターンを描いてそれを実行する（一部今やってる？）、修正のあるファンクションはテストパターンを書き換える。 んなかんじ？ でもマルチタスク、マルチスレッドとか、結構条件再現させるの難しいのもあるよねー。 この辺もうなんか決まったフレームワークとかあるのかしら。 JavaScriptとかは簡易テストフレームワーク作ったりしたけど、 自前はもうやりたくないよねぇ、今どき・・・