とある秀丸エディタヘビーユーザーの秀丸エディタへの要望

秀丸エディタ

私は秀丸エディタにどっぷり浸かっている。欲しいと思う機能も色々とある。要望と題してざっと書き殴ってみた。

強調表示の設定数を増やして欲しい

  • Actual) 8 + 4 + 4 = 16 個しかない
  • Expect) 32 個くらいは欲しい

理想を言えばn個（制限無し）。たとえば「月、火、水、木、金、土、日それぞれの文字に別の強調を割り当てる」くらいはやりたい（拙作 Tritask 用）し、「スペース2個インデント」と「4個」「6個」「8個」なども別々の色で強調（開発中のアウトライナー文法で使う予定）させたい。今の16個だと全然足らない。

アウトライン解析枠内の表示文字列にキャプチャを使いたい

  • Actual) 解析枠に余分な文字(見出し文法)も表示される
  • Expect) キャプチャを使って余分な文字を省きたい

たとえば Markdown の見出し記法をアウトラインで認識させる場合、大見出しなら正規表現で ^(\#)([^\#]+)$ などと書くのだが、この時、アウトライン解析枠には \2 を指定する、みたいなことがしたい。

今はこの機能が無いため、アウトライン解析枠には常に # xxxx が表示されてしまう。# 部分は邪魔だ。キャプチャ指定に対応していれば、この邪魔部分をカットできる。

複数行コメント内の「行の強調」を無効にしたい

  • Actual) 複数行コメント内でも「行の強調」が働いてしまうため見た目がノイジー
  • Expect) 無効にしたい

今は複数行コメント内でも「行の強調」が働いてしまうため、ちょっと見栄えが悪い。

Grep 機能に指定ディレクトリを除外する設定が欲しい

  • Actual) 除外手段が無いので .git や node_modules があると死ぬ
  • Expect) 除外したい

.git やら node_modules やらを除外したいのだが、秀丸エディタの Grep 機能だけでは除外できない。

.git の場合は拡張子を指定すれば回避できるが、node_modules 内には js ファイルなどもあるので、js ファイルに対して Grep したい場合は詰む。

文字数ダイアログの設定を複数持ちたい or 切り替える手段が欲しい

  • Actual) 設定はグローバルで一つのみ
  • Expect) 複数設定を持ちたい or マクロで変更する手段が欲しい

文字数ダイアログは地味に便利だが、少なくとも「小説用」と「プログラミング用」の二つ分の設定が欲しい。小説用では全角も一文字だが、プログラミング用では（主に Windows で SJIS 扱っている関係で）二文字にしたいことが多い。今は設定が一つしかないので、いちいち文字数ダイアログ上で切り替えないといけない。

「レベル n 以下は全て折りたたみ」が欲しい

  • Actual) foldall(レベル1以下は全て折りたたみ)しかない
  • Expect) レベル2以下は全て折りたたみ、が欲しい

foldall は表示中のテキストを折りたためて便利だが、「レベル1だけじゃなくてレベル2も見たい」と思う時がよくある。「レベル n 以下のみ折りたたみ」のような n の余地があると嬉しい。

できるじゃないか？

いえいえ、私が言いたいのは foldall 0x0020, 0; という「0x0020(アウトライン解析との対応)」による折りたたみ、という前提で、「アウトライン解析で認識されているレベルのレベル 2 以下のみ折りたたみ」がしたい。

ウィンドウ位置とサイズを変えるマクロ命令が欲しい

  • Actual) 位置とサイズを変更できる命令は無い
  • Expect) 位置とサイズを変更できる命令が欲しい

秀丸エディタマクロだけで秀丸エディタウィンドウを完全にコントロールしたい。現状足りないのはウィンドウの位置やサイズを変える命令が無いこと。

Firefox Quantum v64.0 で F12 開発者ツールのデバッガーが動作しない(何も表示されない)

Firefox

Firefox の F12 開発者ツールのデバッガーが動作しない(何も表示されない)現象に遭遇。どのウェブサイトでも一様に発生するので、デバッガー機能自体の不具合と思われる。

発生契機

よくわからないが、Quantum であること＆ここ一ヶ月以内、がキーな気がする。

調べてみると Firefox v52 からデバッガーが刷新されたようなので、このタイミングだと思われる

デバッガー (Firefox 52 より前) | MDN

そういえば手元の Firefox、元は v50 くらいだったが、一ヶ月前くらいにようやく Quantum に変えたんだった。

解決

about:config から古いデバッガを使うようにする。

devtools.debugger.new-debugger-frontend を false にする。

参考

javascript - Mozilla firefox debugger not working - Stack Overflow

I/O、メモリ、CPU使用率……会社の重たい Windows 7 を軽くするのに効果があったこと

Firefox Windows

32bit メモリ4GB Windows7 というシビアな環境で開発を頑張らないといけないマンの話。

前提

  • Windows 7 32bit

方針

  • I/O 処理が重くならないよう I/O 対象（つまりはファイル）を減らす
  • メモリの空きがなくなるとページングが発生して処理が遅くなるので、 メモリの空きがなくならないようにする
  • CPU が使用されると他の処理に回せなくなるので CPU 使用率を使うプロセスを抑える

ごみ箱を空にする(I/O)

20 GB くらいあったので空にした。何十分かかったか。

(効果) 全体的に動作が軽くなった気がする

%temp% 内の一時ファイル/フォルダを削除する(I/O)

サイズは不明だが 10000 以上のファイルがあったようで、これも削除に何十分かかったか。

(効果) 全体的に動作が軽くなった気がする

Firefox 系

Firefox Quantum になってからメモリがとにかく枯渇しやすくなった。Win7 32bit ではビットの制約的にメモリは 4GB しか使えず、その上、システムの予約分や仕様も含めると、実質 3GB ちょっとくらいしか使えないのだが、 Quantum は平気で GB 単位のメモリを食う ので正直苦しい。

集中的に改善することにした。

履歴を削除する(I/O と メモリ と CPU)

アドレスバーから検索してアクセスするために、私は履歴はあえて消していない。結果として数年分の履歴が丸ごと保存されている事態になっており、Firefox が起動後数十秒くらい CPU 使用率を食いまくるという現象が起きていた（たぶん起動時に履歴データを先に全部読むんだと思う）。（測ってないので気のせいかもしれないが）メモリも 0.2～0.3 GB くらいは食っていた。

というわけで、不便なのを承知で、思い切って削除してみた。10 分くらいだろうか、CPU フル回転で削除が走った。

(効果) 起動時の CPU 使用率は数秒で済むようになった。メモリも（測ってないので気のせいかもしれないが）0.2～0.3 GB くらい少なくなったと思う。少し不便（普段アドレスバーから履歴を検索していたのができなくなった）になったが、ブックマークに入れておけば検索できるので大した手間ではない。それに大体ググっちゃうし。

定期的にメモリ解放する(メモリ)

Firefox には about:memory というメモリ管理機能がある。

about:config と同様、アドレスバーに打ち込めばアクセスできる。

この機能の以下を使うと、メモリを解放したり使用量を抑えたりできるので、定期的に使う。タブ一つとして常に開いておくのが良いか。

  • Free memory > GC
  • Free memory > Minimize memory usage

(効果) 特に既にフルフルで動かしている Firefox のメモリ使用量が 0.2～0.4 GB くらい減る。

ページング回避のため関連するアプリを固めて実行する(メモリ)

これは設定というよりもタスク管理の領分になるが、 色んなアプリをテキトーに使い分けているとメモリが不足するので、「このタイミングではこのアプリを使う」というふうに時間帯で区切る というやり方である。

私の場合、PC では以下を使う。

  • (1) Visual Studio Code など IDE 系
  • (2) Firefox などブラウザ系
  • (3) メーラーや IM などコミュニケーションツール
  • (4) PDF, Excel/Word などオフィス文書系

すべてを起動するとメモリが足らないので、1～4 をすべて立ち上げて切り替えていると、どこかのタイミングでページング（メモリ不足に伴う仮想メモリ使用）が発生してしまう、十数秒くらい待たされてしまう。

この問題を防ぐために、1～4 をいつ使うか、をタスク管理などで工夫する。

私の場合、3 と 4 は一日一回だけ実行するようにして、実行した後はすべて終了させている。幸いにも 3 などでリアルタイム性が要求される仕事ではないので、これでも仕事は回る。いわゆる逐次処理ではなくバッチ処理にしている、というべきか。

指定した実行ファイルを呼び出すスケジュールがタスクスケジューラーにあるかどうかをコマンドでサクっと調べる

Windows

重たい Windows を少しでも軽くするため、（余計なプロセスを起動しやがる）タスクスケジュールを停止させたい。しかし、「compattelrunner.exe を起動しているスケジュールはどれだ」ってのがわかりづらい。タスクスケジューラーから一つずつ見るのは苦だ。

というわけで、コマンドでサクっと探せないか検討した。

結論

  • schtasks コマンドで概ね実現できた
  • ただし「複数のコマンドラインを起動するスケジュール」については、このコマンドでは表示されないという弱点がある

前提

  • Windows 7

基本形

schtasks コマンドを使う。

$ schtasks /query /fo csv /v
"ホスト名","タスク名","次回の実行時刻","状態","ログオン モード","前回の実行時刻","前回の結果","作成者","実行するタスク","開始","コメント","スケジュールされたタスクの状態","アイドル時間","電源管理","ユーザーとして実行","再度スケジュールされない場合はタスクを削除する","タスクを停止するまでの時間","スケジュール","スケジュールの種類","開始時刻","開始日","終了日","日","月","繰り返し: 間隔","繰り返し: 終了時刻","繰り返し: 期間","繰り返し: 実行中の場合は停止"
...

あとはこれをテキストエディタ等に貼り付けて、実行ファイル名で検索する。

コマンドだけで完結する

パイプで findstr に渡す。

$ schtasks /query /fo csv /v | findstr /i "compattelrunner.exe"
"XXXXXXXXXX","\Microsoft\Windows\Application Experience\ProgramDataUpdater","2018/12/14 0:48:21","準備完了","対話型/バックグラウンド","2018/12/13 1:08:48","0","N/A","%windir%\system32\compattelrunner.exe -maintenance", ...

ただし findstr はクセが強い上に貧弱なので、grep コマンドがあるならそちらを使うべき。あるいは素直にテキストエディタで頑張る。

(注意点) "複数のアクション" の罠

各スケジュール設定が実行するコマンドラインは、タスクスケジューラーでいうと「プロパティ > 操作タブ」内に相当する（もっというと「プログラムの開始」操作）が、ここが複数指定されていると、上記の schtasks /query には "複数のアクション" とだけ表示される。

言い換えるとコマンドラインが見えないので検索してもヒットしない。

この問題は schtasks コマンドだけでは解決できないっぽい。PowerShell を使えばできるみたいだが……。

参考: windows 7 - How to make SCHTASKS /Query display the "multiple actions" attribute in query result? - Super User

指定ホットキーで指定ウィンドウをアクティブにする (AutoHotkey)

AutoHotkey Altab

Alt + Tab で切り替えるのは面倒くさい。特定のホットキーで一発で切り替えられたら便利だ。AutoHotkey でサクっと実現できることがわかった。

実現したいこと

  • Win + 1 で秀丸エディタをアクティブにする
  • Win + 2 で Firefox をアクティブにする
  • Win + 3 で秀丸エディタ（のうち .ahk ファイルを開いているウィンドウ）をアクティブにする

スクリプト例

; ウィンドウアクティブ化時にタスクバーアイコンが点滅する現象が起こらなくなる
#WinActivateForce

#1::
  WinActivate, ahk_exe hidemaru.exe
return

#2::
  SetTitleMatchMode,2
  WinActivate, Mozilla Firefox
return

#3::
  SetTitleMatchMode,2
  WinActivate, .ahk ahk_exe hidemaru.exe
return

解説

基本的なアイデア:

  • リマップにより「指定キーを押すと指定コマンドを実行する」設定を登録
    • 指定キー = Win+1 など
    • 指定コマンド = 指定ウィンドウをアクティブにする命令
  • 指定ウィンドウのアクティブは WinActivate コマンドで行う

WinActivate は「指定したウィンドウをアクティブにする」コマンド。

問題は「指定したウィンドウ」をどうやって指定するかだが、色々ある。詳しい解説は以下に譲るとして、

ここでは三種類ほど。

WinActivate, ahk_exe hidemaru.exe

上記は実行ファイルによる指定。秀丸エディタは hidemaru.exe。

SetTitleMatchMode,2
WinActivate, Mozilla Firefox

上記はウィンドウタイトルの部分一致による指定。Firefox のウィンドウタイトルに必ず含まれる「Mozilla Firefox」を指定している。

ちなみに一致判定はデフォでは前方一致なので、SetTitleMatchMode にて部分一致(=2)にしている。なお、SetTitleMatchMode はリマップの内側に書く必要がある。

; これは動作しない。
SetTitleMatchMode,2

#2::
  ; ★こっちに書く必要がある
  WinActivate, Mozilla Firefox
return

最後に、もう一例。

SetTitleMatchMode,2
WinActivate, .ahk ahk_exe hidemaru.exe

上記は「ウィンドウタイトルに .ahk を含む」 かつ 「実行ファイル名が hidemaru.exe」にマッチする。秀丸エディタは今開いているファイルのファイル名をウィンドウタイトルに表示するので、上記は結局「ahk ファイルを開いている秀丸エディタウィンドウ」を示すことになる。

おわりに

Alt + Tab から脱却できそう。

p.s. そういえば以前、Win + Cursor ベースでウィンドウを切り替えるツールをつくったりしたが、結局使ってない。。。

stakiran.hatenablog.com

「割り込み」や「あとでやる」をサクっと管理するのに GitHub Projects が便利そう

GitHub 管理(タスク管理)

割り込みやひらめきをサクっとメモして管理することは意外と難しいが、個人的に馴染み深い GitHub で、グラフィカルにサクっと管理できそうな方法を見つけたのでまとめてみる。

画面

f:id:stakiran:20181203191836j:plain

カラムは三つ。左がゴミ箱、中が今日やるもの、右が明日やるもの。

基本的な運用

  • (1) 割り込みが起きたり「あとであれやっておこう」がひらめいたりしたら、中カラムの「今日やる」にカード(Note)を追加しておく
  • (2) 「今日やる」は空いたタイミングで見る。消化したら左のゴミ箱に移す
  • (3) 「明日でいいや」は右の「明日やる」に移す

目標として 今日中に「今日やる」をゼロにする を掲げる。

明日になったら

「今日やる」を整える。

  • (1) 中カラムを「今日やる」→「明日やる」にリネーム
  • (2) 右カラムを「明日やる」→「今日やる」にリネーム
  • (3) 右カラムと中カラムを入れ替える

運用時のコツやポイント

テキトーに書く

ちゃんとした文章で書こうとしない。キーワードやコピペでいいし、律儀に漢字変換したり助詞を書いたりする必要もない。

ちゃんと書こうとするとハードルが上がってしまい「メンドクセ」となってしまう。

適当なタイミングで見返す

せっかく「今日やる」にメモしておいても、ここを後で見返さなければ意味がないので、見返すようにしておく。

厳密にやるとタスク管理の領分になるので割愛するが、簡単にやりたいならアラームやリマインダーをセットする。たとえばカレンダー機能で 17:00 に「今日やるを見て！」的な予定を入れておくとか、cron に慣れてるなら 17:00 に「今日やるを見て！」を表示するコマンドが実行されるよう仕込んでおくのもいい。

ゴミ箱が溜まったら Archive する

Archive all cards を使ってアーカイブする。

ちなみにアーカイブしたカードは Menu から参照・検索できる。

f:id:stakiran:20181203191910j:plain

Q&A

Q: 明日になったらリネームせずとも明日カラムから今日カラムに移せばいいのでは？

Ans: 構わないが推奨はしない。

なぜなら「明日やる」カラムから「今日やる」カラムに移す時に、「これは今日もやらなくていいや」と判断して移さなくなるカードが生じるから。そういうカードは何日もずっと「明日やる」に滞留することになる。

上記のリネーム方式だと、毎日「今日やる」にカードが入るので、滞留を防ぎやすい。

Q: CLI でサクっと実現すればいいのでは？

Ans: できるのならそれが良い

ブラウザでの操作はなんだかんだ面倒くさいので、CLI で完結してもよい。たとえば today.md と trash.md と tomorrow.md をつくっておけば実現できる。

ただ、やってみるとわかるが、目に見えない CLI ベースでこういう運用をするのが意外と負担が高い。GitHub Projects のように、目ではっきり見える方が案外やりやすかったりする。

おわりに

このやり方、どうかな。

私はタスク管理ツールを使っているのでこのやり方は運用していないが、このやり方は「タスク管理ツールはよくわからん」「勉強するのしんどい」という方、かつ GitHub にある程度慣れてる方なら、ごく自然に使いやすいのではないかと思っている。

チャットで応答が悪い（返信が遅い）人の特徴 6 つ

チャット

「とりあえず口頭で」な風土を撲滅させるために、チャットの活用を推進しているのだが、中々に根が深いことがわかってきた。一言で言うと、理由や事情は様々だが、チャットという「スピーディーにタイピングで文章を打つ」ことが不得手になってしまっている人が多数存在する。

これを「チャットで応答が悪い（返信が遅い）人の特徴 6 つ」と題して、まとめてみたい。

※このタイトルに挑発や見下しの意図は無い。他に適切なタイトルが思い浮かばなかっただけである。

1. タイピングが遅い

そもそもタイピングが遅ければチャットのハードルはグンと上がる。極力使いたくないと考えるのは自然な発想だ。

しかし、この原因はクリティカルではないと私は感じている。というのも、タッチタイピングができる人の中にも応答が悪い人は多々存在するからだ。

2. 文章で表現することに慣れていない

私はソフトウェア会社に勤めているが、仕事内容はどちらかといえば作家と編集者でいう編集者に近い。また、昇進すると管理職となり管理業務に追われる。

いずれにせよ、仕事中の行動としては何かを書くために手を動かすよりも 口を動かしていることが圧倒的に多い。あるいは煩雑な資料やメールを読んだり、マウスベースの社内システムを使うことに忙殺されている。実際、仕事風景を見ていると、過半数は打ち合わせをしているか、マウスを握ったまま画面とにらめっこしている。キーボードをガシガシ叩いている人間は少数派だ。

で、本題だが、そのような人たちは 言いたいことを文章で表現することに慣れていない。口頭であれば外向けの丁寧な表現であろうと、内輪向けのラフな言い方も瞬時に喋れるが、文章になるとそれができない。

どうも私が見た限りだと「文章＝ちゃんと書く、しっかり書く、マナーや礼儀にも留意する」と捉えている節があるように思える。なんというか、非言語コミュニケーションの 非言語の部分をすべて文章に反映させるのに苦心している というべきか。いわゆる作文である。文章での発言＝作文、だからコストがめちゃくちゃ高い。

当然、チャットもそのコストが高いものに含まれる。気軽に発言するにはハードルが（コストが）高いのだ。

3. 文章という「形に残り続けるもの」を残すことに抵抗感がある

文章でコミュニケーションすることのデメリットの一つは ログが残る ことだ。もっと言えば 後でごまかせない。お茶を濁せない。チャットメッセージというログを残すことは、いわば形に残る弱点を蓄積するようなものである。この事実に耐えられないのだ。

実際、僕の観測範囲でも、昇進や評価を気にしないような変わり者は発言頻度が高く、また内容もフランクである。一方、そうではない大多数の人間は基本的に沈黙を保つ傾向にある（ただし身内のみが集まったプライベートなチャンネルではその限りではない）。

今まで複数の部署で、複数のチャット環境に触れてきたが、アクティブ（常時ログインし、身内プライベート以外で複数回発言している）な人数の割合は 5～15% くらいだった。この傾向はどこでも同じだった。数十人規模のチャットでも、数百人規模のチャットでも同じだった。たぶん（外も含めて一般的かどうかはさておき少なくとも会社内では）一般的なのだろう。

4. PC が重い

私のごく限定的で閉鎖的な観測範囲ばかりで申し訳ないが、重たい Windows をそのまま使っている人があまりにも多い。文書ファイル一つ立ち上げるのに 10 秒以上待っている人はザラだし、中には分単位の待ち時間を平然と受け入れている人もいる。

そういった人の PC を見てみると、デスクトップにファイルは散らかっているし、ブラウザは IE のままだし、セキュリティソフトのスキャンやアップデートも馬鹿の一つ覚えみたいに毎日（それも業務時間中に）回しているし、不要なアプリを終了させずに立ち上げっぱなしでタスクバーには何十個とタスクボタンが並んでいる。PC が重たくなるのも当然だ。

一方、たとえば私の例でいうと、PC は重くならないよう設定を工夫している。デスクトップにはファイルを置かないやり方をしているし、ブラウザは Firefox（少なくとも IE ではない）だし、スキャンやアップデートのスケジュールは社内ルールに逸脱しない範囲で頻度を落とし、また時間帯を工夫している（例: PC を触らない昼休憩中にする）し、不要なアプリは落としている。他にも細かいテクニックを含めば何十と実施している。

おかげで PC はあまり重くない。チャットで発言しようと思っても、すぐに発言できる。ウィンドウの切り替えには数秒もかからない。一方、重たい人は、数秒どころか十数秒かかることもざら。これでは発言に抵抗感が増えるのも無理はない。

5. 道具が貧弱である

昨今のセキュリティやら働き方改革やらの影響で、キーボードもタッチパッドも使いづらく画面も狭いシンクラ端末だけを使って仕事をしている人が増えている。しかし、そんな貧弱な手段だと、チャットウィンドウに切り替えて発言するという行動もやりづらく、抵抗感が増す原因になっている。

逆に、このあたりを改善すると、発言までの行動コストがだいぶ減る。たとえばキーボードを打ちやすいものにして、マウスも使って、画面をデュアルにすれば、セカンダリモニタに開いているチャットウィンドウに Alt + Tab なりマウスクリックなりでアクセスするだけで切り替えられるし、発言も打ちやすいキーボードでサクサクできる。

この差は意外と大きい。私もシンクラを使うことがあるが、発言ペースは明らかに落ちる。切り替えるのが面倒で、また打ちづらくて、チャットする気が失せるのを自覚する。

6. 仕事のやり方が下手（というより知らない）

メールばかり見ていては仕事にならないように、チャットばかり見ていても仕事にならない。そのため あまり見ない（まあ見なくてもいいや。何かあれば上がってくるし） 、と割り切る人は意外と多い。特に物理的に忙しく、また（チームや部下に対する）ある程度のわがままが許容されやすい管理職やリーダーはこの傾向が強く、自分宛のメッセージをしばしば（無意識あるいは意図的に）ロストする。

これは多くの場合、 仕事のやり方が下手（というよりやり方を知らない）なだけだ。

チャットに新着がある度に即反応していては、集中できないのは当然。きりのいいタイミングで一日数回「まとめてチェックする」ようにすればいい。また、チェックするにしても、読んだものを片っ端から処理するのではなくて、いったんタスク管理に入れるだけに留める。それで一度メッセージを処理しきって、その後でタスクの実行順序を考える（もちろん GTD に代表されるように 2 分で終わるタスクはその場で済ませる、などのテクニックも必要だが）。そうすれば漏れはないし、遅くとも 2 日以内には返信できる。

物理的に処理量が多すぎるなら、それは仕事のやり方以前の問題だ。仕事を減らすようチームやステークホルダーに働きかければいいし、そうするべきであろう。承認フローや相談タイミングの見直しやルール化を検討してもいい。また、他にも――ときりがないのでこのくらいにしておく。

「なんとなく適当に衝動的にこなす」ではなく、もっと賢くシステマチックにこなす、という仕事の基本が意外と知られていないのだ。

……まあ無理もないだろう。タスク管理をはじめ、このようなテクニックは学校で習うわけではないし、会社が教えてくれるわけでもない。よほど意識が高くてハイレベルな環境で過ごしているか、そうでなければ読書や趣味で嗜まない限り、知ることはできない。閉鎖的に、会社内でバリバリ仕事をしているだけでは知りえない。

おわり

以上、かなり雑多で主観的で散文的になったが、チャットの利活用を阻む原因として「個々の性質」があり、具体的に 6 つほど性質を挙げてみた。

改めてまとめておく（下記は更に分類して 4 つだが）。

  • 能力が低い(タイピングスピードが遅い)
  • 道具が悪い(PC が重い、周辺機器が貧弱など)
  • 心理の問題(文章で表現することに対する抵抗感, 不慣れ, リスクなど)
  • 忙しい(タスク管理などを知らず要領よく捌けていない)

チャット推進の道のりはまだまだ遠そうだ……。

言語バーが邪魔なのでデフォルトで非表示にする＆必要な時にだけ表示する

IME Google日本語入力

Google 日本語入力が前提（たぶん他の IME でもいけると思うが）。

Windows 7 の場合

言語バーの表示/非表示設定方法

コントロールパネルの「テキスト サービスと入力言語」から行える。

コマンドは control input.dll。

[言語バー] タブの [言語バー] グループボックスから設定できる。ここを「表示しない」にしておくと表示されない。

表示したい時は？

ファイル名を指定して実行などから control input.dll を呼び出して、上記「表示しない」を解除する。

Windows 10 の場合

暗記できないレベルで長ったらしくなる。

Rundll32 Shell32.dll,Control_RunDLL input.dll,,{C07337D3-DB2C-4D0B-9A93-B722A6C106E2}

下記の元記事にもあるように、ショートカットなどをつくっておくのが良さそう。

参考: Create Text Services and Input Languages Shortcut in Windows 10

一時的な単語登録「TSTE(Temporary Slot of Text Expansion)」について

文字入力

TSTE(Temporary Slot of Text Expansion) とは、 よく使う単語を一時的に Text Expansion に登録する こと。

Text Expansion（に限らず文字入力効率化全般に言えることだが）では、よく使う単語を 「恒久的に」登録する という前提がある。

そうではなく、「一時的によく使う単語」をとりあえず登録しておいて、不要になった削除する――というのが、この TSTE。

例

私は最近、タスク管理関連の記事で「MUST TODO」「WANT TODO」という二つの概念を取り上げた。

※予約投稿中なのでまだ記事は無し。気が向いたら後でリンク張る。

当然ながら、これら二つの単語は頻出する。しかし「MUST TODO」にせよ「WANT TODO」にせよ打ちづらい。全部大文字だし。

だから 一時的に Text Expansion で素早く打てるようにする。

私は AutoHotkey を使っているのだが、以下のようにした。

::1@@::
    Clipboard = MUST TODO
    Send,^v
return

::2@@::
    Clipboard = WANT TODO
    Send,^v
return

これで 1@@ と打つだけで MUST TODO が入力される。

※AutoHotkey 自体の詳細は取り上げない。こちら等を参照のこと → AutoHotkey の Hotstrings(ホットストリング) はクリップボードを使うと動作が安定する - stamemo

TSTE のコツ

省略語はスロットにすること

スロットとは 1,2,3... あるいは a,b,c... あるいは q,w,e,r...(キーボードの配列順) のような、並び順ベースの割り当てのこと。

TSTE では、このスロットに単語を割り当てるイメージになる。

「MUST TODO だから略して mt、あるいは先頭をいじって mst……」なんてことは考えない。それでは登録が億劫になる。 登録作業はえいやですぐに済ませたい。スロットならば上手くいく。

Text Expansion の設定画面を素早く呼び出せること

いちいちマウスクリックを何回もして呼び出す、というのは億劫である。

可能ならショートカットキー一発で呼び出したい。

私は AutoHotkey なので、以下のようにして Ctrl + Alt + E で一発である。(E は Edit の E)

!^e::Run,"C:\Program Files (x86)\Hidemaru\Hidemaru.exe" %A_ScriptFullPath%

; これは Ctrl + Alt + R でリロードを行うホットキー.
; 編集後はリロードが必要なので, このホットキーも入れておくと良い.
!^r::Reload

おわりに

TSTE(Temporary Slot of Text Expansion) は僕の造語だが、便利であるにもかかわらず見落とされている視点であるように思う。

Text Expansion でステノワードを実現できないかな、という話

文字入力

喋るより早く打てるステノワード(※1)。あれを PC 上で実現できないかなぁと考えて、Text Expansion を駆使すればいけるんじゃないかと考えている。

予備知識その1

ステノワード

字幕放送で使われているキーボード。肝は「1番目のキーと3番目のキーと5番目のキーを同時押しすると、XXXX という単語が入力される」のように 同時押しのパターンに（よく使われる）単語を充てる というもの。これにより一単語を（実際は同時押しだがほぼ）一打鍵で入力するという驚異的スピードを実現できる。字幕放送にも追いつく。

参考:

スピードワープロ学院

ステノワードに関する教育(有償)を行っている組織。たぶん国内唯一。

ちなみに「スピードワープロ」という単語は、ステノワードが商標だからと代わりに考えられたのだと思う（詳しい方いましたら正確な情報など教えてください）。

参考:

予備知識その2

Text Expansion とは？

パターン（単語とテキストの組）を登録しておくと、その単語(入力語と呼ぶ)を入力しただけで即座にテキストが挿入されるという文章入力システム。

  • パターン例: HTML の li タグを入力する例
    • 入力語: li[
    • テキスト: <li></li>

辞書変換や定型文ツールとは違い、余分な変換作業は要らず、またウィンドウも表示しないので、たとえば Windows のファイル名編集中でも挿入できる。

qiita.com

本題

Text Expansion を使えばステノワードっぽいことを実現できるのでは？

案1: 文字キー26個を用いる場合（同時押し不可）

表現可能なパターン数は以下のとおり。

  • 長さ1文字の入力語: 26通り
  • 長さ2文字の入力語: 26*26= 676通り
  • 長さ3文字の入力語: 26*26*26= 17576通り
  • 長さ4文字の入力語: 26*26*26*26= 456976通り

仮に長さ3文字以内までを使うとしたら、26+676+17576=18278 通りのパターンを表現できる計算に。

国語辞書が（辞書にもよるが手元にあるものだと）7万語くらいなので、日本語を網羅するには足りない。頻出語に絞れば、日常会話くらいはこなせそう？

弱点: 同時押し方式ではない

ステノワードの真髄は同時押しである。たとえば abc という三つのキー組み合わせに「コミュニケーション」という単語を割り当てた場合、abc の順で同時押ししても、bca の順で同時押ししても「コミュニケーション」と打てる。

が、この案1 では bca は abc とは別物であるため、bca の順で同時押ししても「コミュニケーション」とは打てない。

案2: 文字キー26個を用いる場合（同時押し可）

ならばと同時押しに対応させてみると、表現力は以下のようになる。

  • 長さ1文字の入力語: 26通り
  • 長さ2文字の入力語: C{26,2}= 325通り
  • 長さ3文字の入力語: C{26,3}= 2600通り
  • 長さ4文字の入力語: C{26,4}= 14950通り

入力語 3 文字以内では 3000 パターンにも満たなくなってしまった。入力語 4 文字まで使えば 1.7 万パターンほど使える。

弱点: 習熟が困難

これは案1にも当てはまるが、文字キー26個の同時押しの組み合わせを覚えるなど、狂気にもほどがある。人間に習得出来るとは思えない。

もう少し負担を減らしたい。

案3: 文字キーを asdf の列にある 8 個のみ用いる場合（同時押し可）

たとえば a,s,d,f と j,k,l,; の 8 キーのみを使うとしよう。

これなら手を常に固定しておけるのでタイプミスは大幅に減る。キー数も 8 個しかないので（26個と比べるとはるかに）学習もしやすいはず。

表現力を求めてみる。

  • 長さ1文字の入力語: 8 通り
  • 長さ2文字の入力語: 28 通り C{8,2}=(8*7)/(2*1)
  • 長さ3文字の入力語: 56 通り C{8,3}=(8*7*6)/(3*2*1)
  • 長さ4文字の入力語: 70 通り C{8,4}=(8*7*6*5)/(4*3*2*1)
  • 長さ5文字の入力語: 56 通り C{8,5}=C{8,3}
  • 長さ6文字の入力語: 28 通り C{8,6}=C{8,2}
  • 長さ7文字の入力語: 8 通り C{8,7}=C{8,1}
  • 長さ8文字の入力語: 1 通り C{8,8}

合計すると 8+28+56+70+56+28+8+1 = 255 255 通りのパターンを表現できる。

……明らかに少ない。

弱点: パターン数が少ない

たかが 255 通りではまともな意思疎通や文章記述は行えないだろう。

ちなみにステノワードはキー 10 個だが 3000 単語以上を表現できるらしい。

案4: 案3に「修飾キー」を実装する

Shift や Ctrl といった修飾キーにより、キー入力の幅が広がっていることは周知の事実だ。これを導入してみる。

まず案 3 では指を 8 本使うので、あと 2 本余っている。これを修飾キーを押す用に割り当てる。

次に、修飾キーを用いてどうパターン数を増やすかには色んなアイデアがあるので、各自見ていく。

アイデア1: 同時押し

修飾キーを押しながら文字キーも押す、というアイデアである。

修飾キーは 2 つあるので、これを m1、m2 とすると、修飾の組み合わせは 4 通りある

  • 何も修飾しない
  • m1 のみ
  • m2 のみ
  • m2 と m2

それぞれについて 255 通りを割り当てれば、計 1020 通りのパターンを実現できる。

アイデア2: スロット切り替え

これは修飾キーにより「どの利用領域(スロット)を使うかを切り替える」というアイデアである。

修飾キーは 2 つあるので、これを m1、m2 とする。m1 では一つ前のスロットを開き、m2 では一つ後のスロットを開くものとする。スロット 1 つには 255 通りのパターンを入れることができるとする。

すると、スロットが n 個あれば、計 255*n 通りのパターンを表現できることになる。

しかしスロット切替時は修飾キーの連打が必要になってしまう。目的のスロットを開くのに、最大で n/2 回の連打が必要になる。

仮にスロットが 10 個だとすると、2550 通りのパターンを表現できるが、スロット切り替えには最大で 5 回の連打を要する

アイデア3: 同時押しとスロットの複合

アイデア1とアイデア2を合わせるとどうなるか。

まず修飾キー m1 には、アイデア1 の同時押し機能を与える。ここまでで表現可能なパターンは、

  • m1 を押さないで 255通り
  • m2 を押しながらで 255通り

なので計 510 通り。

続いて修飾キー m2 には、アイデア2 のスロット切り替え機能を与える。ただし、切り替え方は少し独特にして、m2 を押しながらn番目の文字キーを押すと、n番目のスロットに切り替える、という動作にする。文字キーは 8 個あるから、計 8 スロットが存在する。また、スロットの切り替えは m2 + 文字キーの同時押しだけであり、連打という弱点もない。

まとめると、

  • スロット 1 つにつき 510 通りのパターン
  • スロットは計 8 個ある

ということで全部で 4080 通りのパターンを表現できる。これはステノワードの 3000 単語以上に匹敵するし、もしかしたら勝っているかもしれない。

実装上の課題

ここからは話を変えて、実装の話に移りたい。ステノワードのような「同時押し時に特定単語を入力する」を Text Expansion で実現するにはどうしたら良いか。

課題1. 既存の Text Expansion に「同時押し」という概念はない

Text Expansion というと TextExpander や PhraseExpress あたりが有名か。Windows であれば AutoHotkey の Hotstring 機能を使う手もある。

しかし、いずれにせよ、同時押しに対して単語を挿入する機能は無い。abc と bac は別の入力語として区別されてしまう。両者を同一視する Text Expansion は、私の知る限り存在しない（もしあったら教えてください）。

したがって、本記事は「Text Expansion でステノワードを実現する」というテーマになっているが、答えとしては たぶん無理 となる。やるにしても、同時押しに対して単語を挿入するという独自の Text Expansion を自ら考えて、実装することになる。

課題2. 検出アルゴリズムはどうするか

自力で実装するとして、まず問題となるのは「ある入力語が入力されたことを検出するにはどうすればよいか」という話である。

Text Expansion であれば、abc と入力された場合は、入力バッファに [a, b, c] あるいは [c, b, a] と入っているから、単にこれを調べるだけで済む。もっと賢く実装するなら、1 文字入力される度に照合する手もあるだろう。

しかしステノワードのような同時押しを検出する場合は、そうはいかない。abc について検出するとしたら、同時に acb bac bca cba cab の 5 つについても検出しなければならない。これをスマートに検出するにはどうしたら良いのだろう？

検出アルゴリズムは高速でなくてはならない。なぜならキー入力は（人にもよるが）秒間 10 打は珍しくないし、20 を超えることもあるからだ。検出に時間を要していては間に合わない可能性がある。

課題3. パターンデータをどうするか

ステノワードはパターン（入力語と挿入単語の組）が 1000 以上も存在するが、その中身は明かされていない。スピードワープロ学院で学ぶ以外に知り得る手段はないのだろう。

ということは、パターンデータはすべて自力で作る必要がある。仮に案4のアイデア3(4080通りのパターン)を採用するとしたら、4080個のパターンを考えてデータに落とさなくてはならない。これには「挿入単語として何を使うか」「asd にどの単語を割り当てるか」「よく使う単語には短い同時押しを割り当てよう」などと、それはもう壮大な調査と設計が必要になる。

課題4. 通常の入力とステノワード入力はどう切り替える？

仮に案4のアイデア3(4080通りのパターン)を採用するとすると、a s d f j k l ; の 8 つのキーと、修飾キーとして用いる 2 つのキーの計 10 個のキーは、そのまま使う（本来の働きとして使う）ことができなくなる。これでは当然困る。

通常の入力とステノワード入力。この二つのモードを切り替えるインターフェースが必要だろう。

その他の課題

課題はまだある。

習熟コストの高さ だ。

ステノワード入力を使いこなすためには、何千ものパターンを覚え、瞬時に思い出す瞬発力を身につける必要がある。学院という専門機関で教育させるとおり、一長一短には身に付かないスキルだろうし、少なくとも私は出来る気がしない。QWERTY 配列を覚えるのとはワケが違う。文字通り記憶すべき情報量の桁が違う。

おわりに

ステノワードをソフトウェア的に実現するアイデアについて、Text Expansion をもとに考えてみた。妄想の域を出ないかもしれないが、ステノワードの暴力的スピードに価値があることは確かだ。将来的に、だれかが研究し始め、発展していくかもしれない。

私としてはスピードワープロのようなクローズドな世界ではなく、オープンソースのようにオープンに発展していったらいいなと思っている。

補足

コメントがあったので補足しておく。

(2018/11/16 追記) ※1 「喋るより早く打てる」の根拠について

私は実物を見たり試したりしたわけではないが、以下の動画を視聴してそう思うに至った。

また、以下は「コミュニケーション」という単語を同時押しで打っている例である。

本記事のすべてはこの動画から始まったと言っても過言ではない。また、私が捉えている「ステノワード」は、この動画から得た情報や印象によるところが大きい。

GitHub で Download ZIP した時に改行コードが LF になってしまう件(原因は core.autocrlf)

Git GitHub

Git が使えない方向けに、Download ZIP リンクを貼り付けて「ここから Zip ファイルをダウンロードしてください」という形で配布する方法があるが、このやり方には注意点がある。

Zip 展開後のソース中の改行コードが LF になってしまうことがある。

なので バッチファイルなど LF だと動かないファイル を配布する場合は注意が必要。私は Commainder というバッチファイル製のリマインダーを配布しているが、これが見事に LF まみれになっていた。

原因は何？

抑えておくべきポイントは二つある。

  • (1) Download ZIP はリポジトリ内のファイルをそのまま zip にする
    • つまり リポジトリ内ファイルが LF なら、zip に同梱されるファイルも LF
  • (2) git config の core.autocrlf 次第で、ファイルの文字コードが変わる

つまり (2) の設定のせいで、CRLF でコミットしたつもりでも実際リポジトリ内では LF になっている のが原因。

解決方法は？

二つある。

方法1: .gitattributes ファイルをつくる

.gitattributes というファイルをつくっておくと、指定ファイルの属性を変更できる。属性として「改行コード」にも対応している。

たとえば以下はバッチファイルの文字コードを CRLF にする例。

*.bat  text eol=crlf

方法2: core.autocrlf を false にする

ローカルリポジトリに対して core.autocrlf を false にした上でコミットする。

$ git config --local core.autocrlf false

(参考) core.autocrlf について

core.autocrlf の値次第では「リポジトリにコミットする時」と「リポジトリからチェックアウトする時」の 2 つのタイミングで ファイルの文字コードが変化する。

core.autocrlf は元々、

  • Git「文字コードは基本的に LF でしょ」
  • Windows「うちは CRLF デフォなんだけど……」

という齟齬に対処するために生まれたオプションである。

core.autocrlf では以下の選択肢を用意した。

  • autocrlf=false(何も変換しない)
  • autocrlf=true(コミット時は LF にして、チェックアウト時は CRLF にする。そっちで使う時は CRLF になってるんだから問題ないでしょ？うちもデフォの LF で保存できるし、Win-Win だよね)
  • autocrlf=input(コミット時のみ LF にする。チェックアウト時は CRLF にしないから、LF でコミットしてたファイルは LF のまま扱えるよ。trueよりも融通きくでしょ？)

つまり Git はあくまで LF でのみ保存することを譲らない というスタンスのもと、CRLF 派の Windows が CRLF でも扱えるよう融通をきかせる（コミット時とチェックアウト時にこっそり変換をかける）のである。

(参考) core.safecrlf について

今回調査中にちらほら見かけたのでついでにまとめとく。

複数の改行コードを含む(CRLFとLFを両方含む)ファイルを扱う時、autocrlf だけだとそれら改行コードが (本来は両方含んでいるにもかかわず) LF のみ or CRLF のみ になってしまう。これを防ぐための設定が safecrlf。

具体的には、複数の改行コードを含むファイルがあった時に autocrlf の変換が行われようとすると、警告を出したり操作を中止したりする。

  • safecrlf=false(何もしない)
  • safecrlf=true(混在時に当該操作を中止する)
  • safecrlf=warn(混在時に警告を出すが中止はしない)

参考リンク

秀丸エディタでアウトライナーを実現する試み

秀丸エディタ つくった

マクロを駆使しているが、意外と実現できそうな感触がある。キリのいいところまで出来たので一度リリースしてみる。

ここまでの成果物

GitHub にアップした。

github.com

動作イメージ

こんな感じ。

hidemaru_outliner

操作コンセプト

二段階アクセス。

  • (1) キー割り当て（たとえば Alt + X）などでメニューを出す
  • (2) 操作したいメニュー項目を選ぶ

上記の 2 ステップを踏む。メニュー項目にアクセラレーター( (&X) など)を設定してあるので、実際は (1)のショートカットキー → (2)のアクセラレーターに対応するキーの「キー二回押し」 で済む。

ここで「(1) だけで各操作を呼び出さないのか」と思われるかもしれないが、それだと操作が n 個あれば n 個分のキー割り当てが必要となり、割り当てを考えるのに苦労する。一方、この二段階アクセスなら、割り当ては (1) の一つのみだ。

インストール

GitHub にアップした stakiran/hidemaru_outliner 参照。

  • (1) 上記マクロファイルを入手する
  • (2) 入手したマクロを秀丸エディタに登録する
  • (3) 2 を素早く呼び出せるよう、キー割り当てにて適当なショートカットキーを割り当てる

利用者に求めるスキル

詳しい解説を手抜きしているので、今のところ利用者はかなり限定される。以下が必須。

  • 秀丸エディタで既に「アウトライン解析の枠」を利用していること
  • .mac ファイルからマクロを登録する手順を知っていること

要するに秀丸エディタに慣れている方向け。

もしこのアウトライナー計画が成功したら、初学者向けにも詳しい手順を整備したいと思う。

秀丸エディタでどのようにアウトライナーを実現するか

細かい解説、というか思考過程。

そもそもアウトライナーとは？

アウトラインプロセッサーとも呼ばれる。

文書をアウトライン（見出しと目次）ベースで編集する文書編集ソフトウェアのこと。テキストエディタ、リッチエディタ、Web サービスなどの形態がある。

アウトライナーのメリットは、文書を階層構造で視覚化しながら編集できること。書きやすく、読みやすく、また編集も（見出しの単位でまるごと移動させたりできるので）便利に行える。アウトラインのおかげで、たとえば 10 万字を超えるテキストを編集することも簡単になる。もしアウトラインがなければ、あちらこちらスクロールする地獄に見舞われるだろう。

どのアウトライナー方式を使うべき？

まずアウトライナーには リスト形式 と 見出し形式 がある。

  • (1) リスト形式

リスト形式は、以下のように 文章のすべてが見出しとなっている。

- 大見出し
  - 中見出し
    - 小見出し
      - 本文
      - 本文

つまりリスト形式では、文章は 箇条書きフォーマット になる。箇条書きを超えるフォーマットの文章は書けない。

  • (2) 見出し形式

一方、見出し形式は、以下のように 見出しと本文とが分離している。

# 大見出し

## 中見出し

### 小見出し
本文本文

見出し形式では書籍のような長文コンテンツも書くことができる。ただし、見た目だけでは階層構造を読み取りづらい。

  • どちらの形式が良い？

私はアウトライナーの真価は「長文を階層的に扱うことで視認性と操作性を効率化すること」だと思っているので、本記事では 見出し形式 を前提とする。

秀丸エディタで実現するには

方法は一つしかないと思う。

アウトライン解析の枠 を使うことだ。

これは「表示中の文章に対し、特定のルールで見出し（大見出し、中見出し、小見出し……）を抽出したものを別ペインに表示する」機能である。

このペイン上では、見出し単位でジャンプしたり、折りたたんだり、並び替えたりできる。見出し単位で操作できるというわけだ。

詳しい導入方法などは テキストエディタにアウトラインを導入して快適なテキスト編集を手に入れる - Qiita こちらを参照。

アウトライン解析の枠だけでは不十分

しかしながら、アウトライン解析の枠だけでは、アウトライナーとしていささか物足りない。たとえば、

  • アウトライン解析の枠ではなく 本文領域を折りたたむことができない
  • アウトライン解析の枠は常に全レベルが展開されているため、「大見出しだけ表示する」といったことができない
    • やるにしても枠内で手作業で一つずつ折りたたむ必要があり、手間

追加機能を実装することにした

そこで、上記不満を解消するために、秀丸エディタマクロが持つ機能すべてを眺め、それらを効率的に呼び出す ことを考えてみた。

その結果、見つけたのが以下操作である。

  • 見出しバー > 表示/非表示
  • 折りたたみ
  • アウトライン解析の枠 > 表示/非表示
  • アウトライン解析の枠 > レベルnまで展開
  • アウトライン解析の枠 > 表示位置を●●に

あとは、これらを簡単に呼び出す方法を考えて実装するだけだ。採用した実装内容については、「操作コンセプト」にて上述した。

今後やりたいこと

目次のコピー

アウトライン解析の枠に表示されている内容をコピーする。

マクロでは「7171 ツリー表示：ツリーそのものをコピー」という操作が用意されているので、実現は可能。

折りたたみと枠の連動

秀丸エディタでは「(1) 編集エリア上で見出しを折りたたむ」と「(2) 枠上で見出しを折りたたむ」が、操作系統として異なっている。

(1) は「折りたたみ」として機能が提供されているが、(2) は提供されていない。(2) を実行する唯一の方法は、枠にフォーカスを合わせてカーソルキー左右を使うか、あるいはマウスで +/- のボタンをクリックするかだけだ。

(1) と (2) が表示上、連動していないのは微妙に違和感がある。もっというと (1) で編集エリアを折りたたんだら、それに対応する枠内の見出しも折りたたんで欲しい。この連動が、最も違和感がない挙動だと思っている。

しかし、(2) をマクロから呼び出す機能が提供されていないので、さて困ったものだ。

縦書きアウトライナー

秀丸エディタは縦書きをサポートしている。また、枠としても「7173 ツリー表示：表示方向縦書き」という操作があるし、枠の表示位置を上下に置くこともできる。

つまり 縦書きアウトライナーもできるはず。

小説執筆時に重宝しそうだし、需要もありそうなので、実現してみたいところ。

枠の大きさを変える

現状、枠の大きさ（表示領域）を変更するためには、マウスで枠の端を掴んで D&D するしかない。これは手間だ。ショートカットキーで「狭め」「普通くらい」「広め」あたりを一発で切り替えられるようにしたい。

が、枠の大きさを変更する機能も用意されていないので、実現できない。

見出しの並び替えを効率化

今のマクロでは、見出しを並べ替える操作を省力化できていない。私が並び替えをあまり使わない、あるいは使うにしてもマウスで D&D するからなのだが、並び替えはアウトライナーの特徴の一つなので、もっと積極的に使うべきだろう。当然、素早く呼び出せるようになっている必要がある。

秀丸エディタは以下の機能が搭載されているので、実現は可能だ。

  • 7167 ツリー表示：この見出しだけのレベルを上げる
  • 7168 ツリー表示：この見出しだけのレベルを下げる
  • 7169 ツリー表示：下位レベルも含めて上移動
  • 7170 ツリー表示：下位レベルも含めて下移動

「アウトライン解析」ウィンドウ

「アウトライン解析」ウィンドウという、地味に便利なウィンドウがある。

その他 > コマンド一覧 > その他 > アウトライン解析 から呼び出してみてほしい。これは「アウトライン解析の枠を別ウィンドウで表示した画面」だ。加えて、範囲選択や移動といった操作が行える。 目次を別ウィンドウで俯瞰したい場合 に便利そうだ。

このウィンドウも簡単に開けるようにしたい。

アウトラインについてもっと学んで取り入れる

私はアウトライナーについては無知なので、体系的に学んでおきたい。学んだことや、そこからひらめいたことなどは適宜取り入れていきたい。

ubiteku.oinker.me

秀丸エディタで特定の文字の文字コードを確認する方法

秀丸エディタ

今さら知ったのだが便利である。もう Web ツールやコマンドを使う必要はない。

方法

  • ステータスバーを右クリック
  • カーソル位置の文字コード にチェックを入れる

すると、カーソルの 右側にある文字 の文字コードがステータスバーに表示されるようになる。

利用時の注意点

表示される文字コードはあくまで カーソルの右側にある文字 である。

ハマりがちなのは、一文字分を範囲選択したからといって、その文字の文字コードが出るとは限らない ことだ。具体的に言うと、

  • (1) 前→後 方向に一文字分を選択した
  • (2) 後→前 方向に一文字分を選択した

この 2 パターンがあって、(2) の時だと意図通りに動作するが、(1) の時だと（カーソルの右側にある）範囲選択した文字の「次の文字」 の文字コードが表示される。

ちなみに検索時は上手く動作する

検索キーワードを一文字で検索する際、検索候補も範囲選択されるわけだが、この時は (2) の範囲選択が使われているため、文字コードも正しく表示される。

RealPlayer のサービスやプロセスを一掃するバッチファイル

RealPlayer

RealPlayer は無料でも .avi to .mp4 変換が行える(しかも圧縮率も指定できる)のが素晴らしいところだが、プロセスやサービスがやたら多く、realconverter(変換ツール) を終了しただけではすべて終了されない。手動でいちいち終了させるのも面倒なのでバッチファイルを作った。

バッチファイル

realplayer_killer.bat

@echo off
prompt $$ 
@echo on
taskkill /f /im rpdsvc.exe
taskkill /f /im RPBGConverter.exe
taskkill /f /im realsched.exe
sc stop "RealPlayerUpdateSvc"
sc stop "RealTimes Desktop Service"
pause

プロセスを三つほど強制的に殺し、サービスを二つほど停止させている。

最初の echo や prompt は表示を見やすくするためのおまじないなので気にしないでよい。最後の pause は勝手に黒い画面が閉じるのを防ぐ用（pause するとキーを押すまで閉じなくなるので強制終了の結果が見える）。

おまけ: 動画変換だけ行いたい時の最小解

start_realconverter.bat

@echo off
sc start "RealTimes Desktop Service"
"C:\Program Files (x86)\Real\RealPlayer\realconverter.exe"

まず動画変換ツールは realconverter.exe である。だが、こいつ単体では起動しても動作が重い（おそらく RealTimes 絡みでオンラインで更新を見に行ったりしていると想像するが、他のサービスは立ち上げてないのでそれが行えず、しばらくブロッキングみたいな状態になる）っぽいので、そこを回避するためにサービス RealTimes Desktop Service を立ち上げておく……という感じ。