テレワーク。早くもなく遅くも無く。
東京都コロナ感染者。新規は311人。月曜だしな。
色々弄ったEmacsを普段使いでテストしていたところ、何やら怪しげな動きを
するようになっていたり。
以前入れた変更が w32-ime-buffer-switch-p がnilの場合に
インジケータ表示の同期がうまくできない場合がある副作用がある事が判ったり。
仕方ないので条件を分けてみたものの、コードを見ただけでは何故分ける必要が
あるのか判らないという感じだったり。うーむ。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は418人。
EmacsIMEパッチの単語登録の件。
素の状態から単語登録ダイアログを開く事がどうにもできず。
ただ、MessageBoxダイアログを一度でも開けば、その後は単語登録ダイアログを
開く事ができそうという事から、最初の一回だけ単語登録ダイアログを開く前に
適当な理由を付けてMessageBoxダイアログを開くという、ウルトラ苦肉の策で
対応してみる事に。今まで単語登録機能は提供されていなかったという体で
「こういうものですが何か？」でかわす(かわせてるのか？)という案です。
....負けた気しかしない...orz。
単体テストで確認したところ、単語登録ダイアログには登録単語は設定できるようですが
読み仮名の方は設定できないようなので、
w32-ime.elの w32-ime-toroku-region-yomigana っていう変数をnilから 「""(空の文字列)」
を初期値にして読み仮名入力をさせないようにしたり。あと、W32-IMEが有効でない時も
動かせるようになっていたのでガードをかけてみたり。
ただ、まだ問題があります。w32-ime-toroku-regionで単語登録ダイアログが
開くのですが、ダイアログに「ユーザー辞書ツール」というボタンがあり、
通常なら辞書を編集できるのですが、Emacsのフレームが最前面にある状態だと
辞書ツールの単語一覧の表示が変になります。もう少し言うと単語の文字が表示されていない。
「Emacsのフレームが最前面にある状態」と記した通り、タスクバーの「A」
から右クリックのポップアップメニュー→ユーザー辞書ツール でツールを起動
した場合もダメで、Emacs以外の他のIME入力が有効なウインドウかデスクトップウインドウ(いわゆるルートウインドウ)
がアクティブな状態ならば辞書ツールの単語一覧が正しく表示されるという感じに
なるようです。うーむ？
今回の単語登録ダイアログの件といい、
起動直後にウインドウを動かさないとIMEがONにできない件
(以前の日記)といい、
Emacs側にも何か問題があるのかなぁ？.....とは思ったりも。
SAI2の新しいのが来ていたり。おつかれさまです。バグ修正と調整がメインの模様。
起きたら午後もいい時間。寝すぎ。
東京都コロナ感染者。新規は561人。
EmacsのIMEパッチの中に単語登録を行うコードがあるのですが、
一度も使った事が無いなぁ？と思い w32-ime-toroku-region てのを
使ってみてました。なんとなくエラーする訳でも変になる訳でもない
のですが、正しく動いているのかも判らなかったので調べてみたところ
ImmConfigureIMEというIMEを制御するWin32APIの実行に失敗している
ようだったり。正しく動くとダイアログボックスが開くらしい。
そもそもWindows10でも開くものなのかが判らなかったので、C言語で単体テスト
のコードを作成してみたところ、一応ダイアログボックスが開く
ようだったり。はて、Emacsで開かないのは何故？
HWNDが有効なのかデバッグの為にMessageBoxダイアログを開いてみたところ
開いたのですが、その後で ImmConfigureIME が実行されるとちゃんと開く
事が判ってみたり。ウインドウのフォーカス問題か？と思ってMessageBoxダイアログ
を開くコードを削ってみた後、Emacsのウインドウを動かしてから
ImmConfigureIMEを実行してみるもやっぱりダメ。なんで？
フォーカスを制御してみたりするもダメ。もしやと思ってメニューの
「Options→Set Default Font...」からフォントセレクトダイアログを
開いた後に試すと、 ImmConfigureIME でのダイアログが開いたり。
うーむ。
で、本題はそこでは無くて、単語登録の関数が フォントセレクトと同じくlocale-coding-systemで
文字エンコードを切り替えていたのでlocaleに依存しないように対応する必要がありそうってのに気づいた事でした。
元々、W系のImmConfigureIMEWを使用するようになっているのですが、
引数には REGISTERWORDのA系の変数が使われてるようになってました。
即ち関数はW系なのにその引数はA系という事で(多分)何をやっても文字化けする感じになってました
(パッチの中身を全然見たこと無くてすみません(^^;)。
ひとまずダイアログ自体は開けるので、W系対応した文字がダイアログに伝わっているかを
確認。単語の方は大丈夫そうですが、読みの方は設定してもダイアログには反映されないみたい。
こういうものなのか否かは不明。
という訳で、ダイアログが開かないのをどうにかする必要があるのですがどうしたもんか....
テレワーク。気持ち早めに終了。
東京都コロナ感染者。新規は570人。
3DCGアニメの「ルパン三世 THE FIRST」。
キャラのしぐさに 一瞬 ディズニー/ピクサーっぽい雰囲気があるようにも思ったりも。
ただ、野外のシーンで 何故か見た目が狭く見える場面があるように思ったり。
ちょろりコーディング。なんか反応していないような。
久しぶりの出社。遅めに終了。
東京都コロナ感染者。新規は481人。福岡がダメになり始める兆しが見えている気も。
あまりの眠さに急速停止。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は401人。
酒類を提供する飲食店の時短営業。そこなの？とは思いますが、
もしそうだとするのなら、今コロナに感染する奴は「バカなの？」
と思わざるを得ません。どうにも「人が動けば感染は広がる」という事が
言われていますが、「感染対策が不十分な状態で人が動けば感染は広がる」と
言う人を見たことがありません。
感染拡大するのは人災です。敵はコロナでは無くて人だと思います。
もうすっかり忘れられているようですが、「with コロナ」とか
「自粛から自衛へ」をかざしている以上は、
以前記した通り
「もし第N波が起こった時、その原因は感染予防のできていない奴らだからな！」
とちゃんと言えば？と強く思います。
「いやぁ、そうは言ってもねぇ....」って奴はぶった切るくらいの姿勢で
望まないといよいよダメだと思います。結局は「ちゃんとヤレや」ただそれだけだと思います。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は186人。休日進行な気が。
フォント。Emacsでいくつかフォントを表示してみて見比べてみたところ、
メイリオ(MeiryoKeですが)は少しアンチエリアスのかかり方に
特徴があるように思ったりも。
画像を拡大しないと判りにくいと思いますが、例えば「梅ゴシック」のx1.0の「目」を見ると
三画目の横線が二つのピクセルの間に描かれている為、アンチエリアスの都合で
線が太くなっています。個人的にはこれが「ダマ」に見えるのでイマイチに感じるのかも知れません。
しかし、メイリオはどういう訳か上手く1ピクセルで描かれていて太くなっていません。
あと、メイリオは一文字が枠のギリギリまで使って描かれている為か、同じ
サイズの他のフォントよりも文字が大きく見えます。この点もやっぱり
メイリオに戻ってしまう理由かも知れません。
ただ、先日も記した通り、フルHDの100% 表示で9ptくらいに相当する
x0.7の「目」と「自」は見た目の区別は付きません(^^;
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は314人。
ウイルスを生き物扱いするのはやめれ。ウイルス自身が自力で人を見つけて
感染しているようなイメージで話をする人が居るのですが、ウイルス自身が
自力で人を見つけたり、人のいないところで勝手に増えたりする訳では
ありません。人同士の距離が近すぎたり飛沫防護などができていないがために
感染するのは既に判っている事です。
火(ウイルス)と可燃物(人)の関係でしかないので、燃えてる(感染している)
人に近づけば燃え移る 単なる燃焼だと思います。防火(感染対策)せずに
火に近づけば そりゃ燃えるよね。どうにも ウイルスを生き物扱いした話になると、
感染防止対策ができていない事に対する スケープゴートにしているように
思えるのが気になります。
Emacsのフォント設定。フォントフォールバック(指定したフォントでは表示できない場合に
表示できるフォントで代替する事を指すらしい)で希望するフォントを選択する
のはコントロール不可という事で諦める方向で。
フリーフォントの中には読みやすそうなものもあるのですが、
記号とか絵文字が揃っていなかったり、ASCIIコードの0x5Cが
バックスラッシュじゃなかったりと結局 MeiryoKe_Consoleに戻ってしまいます。
フルHDのスケーリング100% 表示では解像度的に「目」と「自」の区別が
つかなかった(以前の日記)のですが、
4Kの150% 表示とDPIスケーリング有りで問題無くなってしまったので、
よっぽど良いフォントじゃないと変えてみようって気にはならなくなってます。
そういやWindows10のアップデート 20H2とか2004って自動で落ちてくる気配が
無さそうなので入れていないのですが、MS-IMEに地雷が埋まっていると
いう噂を耳にしています。今の所
こんな感じの問題があるらしい。
EmacsのIMEパッチとかでも影響あるのだろうか？それにしても、
こんなに色々バグらかしてる上に結構長い期間に渡って直せていないのは
なかなかな感じに思えます。あと4か月ほどで完全に直せそうにないのであれば
1909のサポート延長も視野に入れる必要があるのでは？とは思ったりも。
AM中に起床。
東京都コロナ感染者。新規は391人。
Webを散策していて、Emacsの編集コマンドで
delete-horizontal-space(M-\) や just-one-space(M-SPC) というのが
あるのを知ったり。ほう....
AM中に起床。
東京都コロナ感染者。新規は539人。
そういえば、新規感染者の年代別の割合について。自分でも見てて錯覚しそうに
なるのですが、高年齢層の割合が増えているのを見ると、若年層の感染者数が
減っているように感じます。しかし、絶対数で見ると若年層の人数が
減ってる訳ではないかも知れません。例えば以下のような二つの表があったとしたとき、
|
|
テレワーク。早くも無く遅くも無く遅めに終了。
東京都コロナ感染者。新規は522人。てか北海道の方がやっぱり訳わからん。
Webを検索していて
こちら
の「MS-Windowsでのフォント指定」という文書を知ったり。
これによるとXLFDベースのフォント指定は後方互換のためにサポートされている
と記されていて、
「ん？先日ハイフンを含むFamilyの指定にXLFDパーサを対応したのですが？」
と思ったり(^^; 内部的にXLFDで扱っているからヒドイ目に遭ってたという認識なのですが、
正しくは内部的にもfontconfig由来のフォーマットで扱うのが正解だったのか？
テレワーク。遅めに終了。
東京都コロナ感染者。新規は534人。ダメだこりゃ。
マスク会食。結局 一次感染はそんな理由なのか？って感じ。
ニュース番組でキャスターが「店側がお客にマスクをするように言う事はできない」とぽろっと
言ってましたが、そりゃなんで？ 店側は対策してるんだから店から客に言っても良いと思いますが。
素直に従うかどうかは別ですが。こういう場面では気に入らない客は追い出すと言われる
フランス人とかを見習った方が良いかもと思います。
まぁ、感染防止対策がちゃんと取れないのだったら会食も旅行も
するなは正解。できない奴には資格など無い。
Emacsのソースコード。C言語で書かれた部分でも Lisp_Object型というのが
使われていて、ELISPとのやりとりをできるようになっているのですが、
例えば文字列の場合でも中身を見たり弄ったりしようと思うとどうすれば
いいの？ってなります。gdbのcallコマンドを使ってLisp_Objectを検査したり
中身を見たりする関数を実行するしか無いようですが......とても面倒臭い。
print関数やformat関数のようなものは無いかと思って見てみると
debug_format()って関数があったので使ってみるも、Lisp_Objectを
うっかりポインタ渡ししてしまうとSegfaultしてしまうので辛い。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は493人。急にはねたね気もしますが、グラフで見ると
補完曲線上には乗っている気も。
感染防止が十分であればいくら動いても理論上は
感染拡大する事にはならないハズですが、拡大しているっていう事は感染防止が
十分でないだけだと思います。現在は家庭内感染が多いという事みたいですが、
ここでは何度か書いていますが、家庭内感染は二次感染な訳ですから、
最初に持ち込んだ一次感染の原因を追究して潰さない限りは減らないと考えられます。
少なくとも「家庭内での感染防止を徹底しましょう」.....家庭内に持ち込まれたら
防御なんてできる訳ありません。
なんとなく数の比重だけで要因分析している為か、多い所を減らしましょうって
アルゴリズムになっているように思えます。原因への対応が重要なので、
どこに穴が空いているのか？についてはうやむやになってるように感じます。
それにしても「ふんどしを締めなおす」ってなんだ？とは思います。
先日記した「気が緩んでいる」と同じレベルの
よく判らなさに思えます。オブラートに包まなくて良いのでダメな所をはっきり言えばいいのに。
ダメな所がよく判っていないのなら それが一番の問題なのかも知れません。
GoogleがAIを使って感染者数予測。個人的には数の予測自体になんか意味あるの？
という気はします。何故増えるのか？その原因は？を逆追跡する事はできない
ものだろうか？単なる統計的な予測であればAIじゃなくてもそれなりの
精度でできるんじゃないの？と思います。まぁ、今のDLベースのAIは結局は
統計的予測のようなもんだと思います。AIって枕がついているせいで、
当たればなんかスゴいって思うかも知れませんが、
もし、ハズレても「確実を保証する訳ではない」という言い訳が用意されているのならば、
ただ言った事がたまたま当たっただけで、何の責任も無いインターネットの掲示板の文書と同じだと思うのは、
大分偏った個人的な感想です。
Emacsで何故か「りいポップ角 R」というフォントが選択される件。
どうやらutf8の文字「あ」を使って「(font-at 0 nil "あ")」相当の
Cコードを使ってフォントを得ているようですが、そこで
「りいポップ角 R」が返っている模様。font-atで何故そのフォントが返るのか
やっぱり判らん。でも、ここより大分前に「りいポップ角 R」が存在している事が
認識されているのだろうとは思われ。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は298人。
Emacsフォント設定。うーん、判らん。
テレワーク。早めに終了。
東京都コロナ感染者。新規は180人。月曜だけど多いな。
Emacsでフォントの切り替えを確認しているのですが、どうにも振る舞いがよく判らない
所があったり。メニューバーからの「Options→Set Default Font...」で
フォント選択ダイアログを開くと、フォントの「文字セット」として
「欧文」「日本語」その他の言語を選択できます。「日本語」が選択できない
場合は単純に日本語フォントが含まれていない、「日本語」が選択できる場合は
日本語フォントが含まれているというくらいの感じだと思っていたのですが、
フォントによって振る舞いが違うようでした。
| フォント | 文字セット | ASCII文字 | 日本語文字 |
|---|---|---|---|
| A | 欧文 | 切り替わる | 適当なフォントが選ばれる |
| B | 日本語(case1) | 切り替わる | 切り替わる |
| C | 日本語(case2) | 切り替わる | 適当なフォントが選ばれる |
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は255人。
Emacsのフォント関係であれこれ弄っている経過の中で、ELISPアプリの気になっていた点を直してみたり。
拙作sysmon
ですが、SVG表示した際にフォントサイズを大きくするとそれ以上に拡大されて表示されて
いたのを修正しました。
Emacsでは画像は文字としてレンダリングされますが、元のサイズよりも大きくした場合に
二重にスケーリングがかかっている感じになっていたようです。
アクセサリ更新ついでに
mcalendar
を更新しました。2021年の祝日対応をしています。
以前も記しましたが こんなにカレンダーアプリを
弄る事はもう無い事を願いたいです(^^;
全く気づいていなかったのですが、Cygwinパッケージのemacs-w32って
SVG表示有効でビルドされていないのか。emacs-X11の方は表示可能で、野良ビルドしている
emacs-w32もSVG有効になっているので、パッケージのemacs-w32もイケるようになっている
ものだと思い込んでいました。
数日前にgoogle-translateでの翻訳ができなくなってましたが、
特に何をするでもなくまた翻訳できるようになってました。このパターンは初めてかも。
と思ったらダメな場合があり。どうやら長い文だとダメっぽい。
AM中に起床。
東京都コロナ感染者。新規は352人。
減るにしろ増えるにしろ今の行動の結果が判るのは1～2週間後なので、
今の状況を受けて今後どうするか？が重要なのだと思います。
LOGFONTをW系に書き換える件。文字列をコピーする際のバッファの長さを
間違えていて途中で千切れていたというバグを埋め込んでました。それを直しても
まだダメだったので調べていたところ、src/font.c:font_parse_xlfd って関数でフォントの指定を
行っている文字列をパースするようですが、このフォント指定のフォーマットって
フォント名(Family)に「-」(ハイフン)を含んでいた時にうまくパースできるのか？と思ったら
やっぱりできていなくてエラーしている模様。何これ？
describe-fontでは次のような名前になってました。
name (opened by): -outline-UD デジタル 教科書体 N-B-bold-normal-normal-serif-18-*-*-*-c-*-ascii-0
full name: UD デジタル 教科書体 N-B-9.0:bold
※「UD デジタル 教科書体 N-B」がフォントファミリの指定。「-B」の所でフィールド境界を誤る模様。
テレワーク。早くもなく遅くも無く終了。
東京都コロナ感染者。新規は374人。
Cygwinをアップデートしたところ、環境変数LANGの設定がされなくなっていたり。
しかたないので.bashrcに追記。それにしても何故今？
ひとまず LOGFONTを W系のを使うように書き換えてみたり。UNICODEをdefine
するとコンパイルできなくなるコードとコンパイルできるコードの継ぎ目は
LOGFONTWを明示的に使うというイマイチな感じではありますが。
で、テストしてみるも何故か認識できないフォントがあり、なんで？って感じに。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は393人。感染防止対策ができていないのでしょう。
そういや「気が緩んでいる」という表現をふんわり使っているのをTVの該当インタビュー
映像などで見るのですが、具体的にどういう事を指してそう思うのか？というのは
よく判りません。そもそも何を以ってできている/できていないと言うのか
判っているのかも怪しいように思えます。そういう感じの人が実際に感染したとして
具体的な心当たりを答えられるハズもなかろうと思います。
東京都では393人中、無症状感染が101人という事らしいのですが、
この人達はどういう契機でPCR検査を受ける事になったのだろう？というのは
少し謎に思ったりも。何のきっかけも無く検査して感染者数の 25% もの割合で無症状感染
しているというのはなんか多すぎる気も。発症した人から感染可能性のある人を
効率良く引っ張る事ができているというのなら話は別ですが。
LOGFONTを W系のを使うように書き換え始めてみたところ、あちこちW系に対応しなくては
ならなくなって、もしかしてこれがW系に積極的に書き換えようとしていない理由なのか？
と思ったりも。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は317人。
結局、感染予防ができていないのは店側じゃなくて客の方か。
そういやコロナのワクチンの話で「90% 以上の効果」という言い方に
違和感を覚えました。多分、何に対する効果の割合かが判らないので、
割合だけ言われてもなんのこっちゃ？って思ってしまうのかも知れません。
ドアの電子ロックのモーターの動きがもっさりしてきたので電池交換。
前回交換してからそろそろ2年経つのか。
1年くらいで交換時期って聞いてたのですが、結局時期は関係無く気にならなければ
そのまま使ってしまうなぁ(^^;
あぁ、またgoogle-translateで翻訳できなくなってる。辛い。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は293人。
あまりの眠さに急速停止。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は157人。月曜だしな。でも増加傾向。
それよりも北海道が200人で東京都を上回るっていったいどうなってんだ？
そろそろ分析結果と見解を出すべき。おおよそ感染対策ができていない
という事なのでしょうけど、具体的にどうできていないのかが
毎回よく判らないのでそこんところをちゃんと言えるかどうか。
と書いた所で、何やら政府分科会から緊急提言されたようですが、
なんだ？「さらに踏み込んだクラスター対応」って。やっぱりもにゃもにゃ
してて伝わらない。できてないならもっと強めにこういう所がダメだと
言えば良いのに。誰に対する提言なんだ？ またモーニングショー的な番組で
「国民はこれ以上やりようがないくらい対策をやってる」って勝手に思い込んでる
人が「政府は何もやってない」って言い始めるかもよ？
調べ事。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は189人。
GIMPの2.99.2ってのがリリースされている模様。
2.10.xxから急に3.0に近づいた感が出てます。
C言語でマルチバイト文字の扱いってどうなっているんだろう？と調べてました。
なんとなくUTF8にはそれとなく対応していて、文字列として使用してもそれとなく
コンパイルできてUTF8対応されたターミナルに向けては文字化けとかはしないようです。
文字として認識しているのか否かは判りませんがSJISの時のようにいわゆるダメ文字
を意識する必要は無さそうです。で、wchar_t型でwprintfとかを使ってみるもなんだか
何を表示しているのかよく判らなかったりも。また、WindowsとLinux/UNIX系では
wchar_t型のビット幅が違うとか、また何やら困る感じの非互換があるみたい。
int型のbit幅と同じようなソースコードレベルの非互換
(以前の日記)をwchar_t型でも
繰り広げていたらしい。
D言語ではwchar型はUTF16用の16bit文字型、dcharはUTF32用の32bit文字型となって
いるので、場面によって意味が変わるって事は無かったのを考えると、
C言語のwchar_tは筋が悪いなぁ？とは思います。で、それがやっぱり問題に
なるケースがあるらしく、C11の規格ではuchar.hってヘッダファイルが実装されて、
char16_tとかchar32_tとかいう型が定義されていたりするらしいですが、
Cygwin(というかnewlib)ではuchar.hが(まだ？)無いようでコンパイルエラーとなりました。
なんかstdint.hみたいな事になってるようです。
そういえば、Windows向けのC言語ヘッダではC言語の型をそのまま使わず、
INTやUINTといったようにtypedefで型を再定義しています。
何故いちいち再定義しているのだろう？と思う事はあったのですが、
これだけ定義が曖昧だと言語定義の型を直接使わずに、定義切り替え可能
な仕掛けを間に挟む事で言語仕様の曖昧さを吸収できるようにしているというのは結果的に
意味がある事のように思えたりもします。これ、誰が最初に考えたんでしょうね？
wprintf()を使ってどうなるのか様子を見ているのですが、どうなっているんだか
全然判りません(^^; D言語のwritef()が良しなに振る舞い過ぎているのもあるかも
知れませんが、それにしてもwprintf()の振る舞いはなんだかよく判りません。
もう少し調べてみると、Cygwinでは/usr/include/unicode/uchar.hってのがあって、
これか？と思ってincludeしてみるもchar16_tは認識されず。使い方がよく判りません。
起きたら午後もいい時間。寝すぎ。
東京都コロナ感染者。新規は294人。神奈川もダメだな。
発症時期から逆算するに先週の10月31日～11月3日がダメだったんでしょう。
調べ事。よく判らず。
テレワーク。少し早めに終了。
東京都コロナ感染者。新規は242人。
あまりの眠さに急速停止。
テレワーク。遅めに終了。
東京都コロナ感染者。新規は269人。北海道はおかしくね？
寒さと関連付けてる人も居るようですが、単に脇が甘い集団の中に
感染源が入って広がっている、一時の沖縄のような状況だと思われる.....
というのが個人的な感想。根拠は無い。ただ、正しく感染防止ができていれば
いくらなんでもこんな結果になるハズが無い。
コマンドラインのdiffを使っていて、差分があるのは判るけどどこが違う
のか直ぐに判らない事が極まれにあります。例えば16進ダンプで b と 6 の違いとか。
コマンドラインで使えると言えば vimdiffなるものもあり、これも悪くは
無いのですが、表示がうるさくてなんだか見づらいと思いました。
そういう時は Emacs の ediffを使いたくなる訳ですが、二つのファイルを読み込んで
ediff-buffersを起動して....と diffコマンド感覚でちょろっと使うのに比べると流石に
煩わしく感じます。
そんな訳で Emacsの--eval オプションを使って ediff-filesを
起動すればいいんじゃない？と思って試してみたら良い感じだったので、
シェルスクリプトでラッピングしてコマンド風にしてみたり。
#!/bin/sh
CMDNAME=`basename $0`
EMACS="emacs"
EMACS_OPT=("-Q")
EDIFF_SETTING="(setq ediff-window-setup-function 'ediff-setup-windows-plain)"
EDIFF_HORIZON="(setq ediff-split-window-function 'split-window-horizontally)"
usage_exit(){
echo "Usage: $CMDNAME [OPTIONs] file1 file2"
echo ""
echo " -n : no-window."
echo " -g : GUI mode if GUI build emacs."
echo " -r : reverse video."
echo " -v : vertical split."
echo " -h : print this help."
exit 1
}
FLG_n=1 #default no-window
FLG_v=0
FLG_r=0
while getopts ngrvh OPT; do
case $OPT in
"n" ) FLG_n=1 ;;
"g" ) FLG_n=0 ;;
"r" ) FLG_r=1 ;;
"v" ) FLG_v=1 ;;
"h" ) usage_exit ;;
* ) usage_exit ;;
esac
done
shift $((OPTIND - 1))
if [ $FLG_n == 1 ]; then
EMACS_OPT=("${EMACS_OPT[@]}" "-nw")
fi
if [ $FLG_r == 1 ]; then
EMACS_OPT=("${EMACS_OPT[@]}" "-r")
fi
if [ $FLG_v == 1 ]; then
EDIFF_SETTING="${EDIFF_SETTING} ${EDIFF_HORIZON}"
fi
if [ $# != 2 ]; then
echo "Error: Number of arguments must be two."
exit 1
fi
ARGS=()
for arg in "$@" ; do
ARGS=("${ARGS[@]}" $arg)
done
for arg in ${ARGS[@]} ; do
if [ ! -f $arg ]; then
echo "Error: $arg does not exist or not a file."
exit 1
fi
done
$EMACS ${EMACS_OPT[@]} --eval "(progn ${EDIFF_SETTING} (ediff-files \"${ARGS[0]}\" \"${ARGS[1]}\"))"
exit
テレワーク。遅めに終了。
東京都コロナ感染者。新規は122人。
アメリカ大統領選挙。え？接戦なの？マジで？
美人時計稼働でのEmacsスローダウン。どうやら、emacs-w32でマルチフレーム
(C-x 5)にしてどちらかのフレームで美人時計を動かしたときに再現する模様。
シングルフレームだと再現しそうになく、emacs-X11のマルチフレームでも
再現しそうにありません。なにこのピンポイントな条件。
AM中に起床。
東京都コロナ感染者。新規は209人。跳ねてるな。
ここ数日Emacsを弄ったついでのテストで
拙作のアクセサリ
類を諸々立ち上げたまま長時間起動しておくという事をやってたのですが、
どうも美人時計を立ち上げたまま数時間経つとウインドウの切り替え時とかに
CPUが高負荷のまま応答無しになったり。少しすると回復して普通に使えるっぽく
なるのですが、また放置しておくと同じ状況になるという性能問題が見えています。
GCなどに関係するのか？と思って「(setq garbage-collection-message t)」
とかにしておいても特にメッセージは無く、イマイチ何が起こっているのかよく判らず。
Cygwinオリジナルのemacs-w32.exeバイナリでも再現するようなので 27.1に何かあるのかも知れず。
気づいていなかったのですが、term+で開いたターミナルが何故か ReadOnlyバッファ
で開いているようで、ヤンク(ペースト)ができなくなっていたり。
手動でReadOnlyを解除(C-x C-q)すればヤンクできますけど、そもそも最初が
ReadOnlyになっているのはなんで？って感じ。
term+のモードラインは専用のタブ表示になっているので見た目では
判断できず。
tr-emacs-ime-module
(tr-ime)の細田さんより
w32-ime-buffer-switch-p を t にした時のtermとIMEの相性問題
の原因について教えていただきました。ありがとうございますm(_'_)m
Emacsでは表示を更新する際はバッファを切り替えたりウインドウのフォーカスを
切り替えたりする必要があるのですが、その時に select-window が実行されます。
そしてIMEパッチではselect-windowの実行でhookを実行するようにしていて、
w32-ime.elはIMの状態を同期するトリガとしてそのhookを使って ウインドウが
切り替わった時にIMの状態にEmacs内のcurrent-input-methodを連動させています。
問題は select-windowが 例えば other-window(C-x o) のように人の都合でウインドウを切り替えた場合と、
画面更新のように一時的に切り替える(終わったら元のウインドウに戻す)場合の両方に
反応してしまう点にあります。画面更新のような場合はIM入力する気は無いのでIMの状態同期は
実行したくない訳ですが、無条件に実行されてしまうので IMがOFFのウインドウに
切り替わるとそこで共通リソースのMS-IMEの状態がOFFになってしまいます。これが
入力中にも関わらず勝手に確定してしまう原因でした。という訳で、
select-window実行時に呼ばれるhookの中で 一時的なウインドウ変更か否かを
判別しなくてはならないという感じなのですが、.........どうやんの？って
感じになりました(^^; src/window.c を見回した結果、
関数old-selected-window というのがあって、この関数で得られたウインドウは
今のウインドウの一つ前のウインドウが示されていて、どうやら一時的な
ウインドウ切り替えの時に元のウインドウに戻す為に覚えておくスタック
(かどうかは判りませんが)のようなものらしい事を知ったり。
という訳でhookで呼ばれる関数を
(defun w32-ime-select-window-hook (old new)
(when (eq new (old-selected-window))
(w32-ime-sync-state new)
))
テレワーク。遅めに終了。
東京都コロナ感染者。新規は87人。月曜だしな。それよりも北海道がおかしくね？
市中感染が広がっていると言っていますが、広がる理由は感染防止対策ができていない
からだと思います。何故自然に広がっているかのような印象で言うのか不明。
Emacsでフォントの heightとsizeの比が大きい場合について。
正解はひとまず置いといて、heightとsizeとの比が1.1倍より大きい場合は
アセント値とディセント値を sizeで正規化するようにしてみたり。
倍率が大きすぎて表示が妙になるのが抑えられた気も。
そういえば、先日の A系のWin32APIについて。マルチバイト文字がSJIS(cp932)で
扱われるっていうのは日本語版のWindowsだけだと思われるのですが、
他国ではどういう扱いになっているのだろう？と思ったりも。
少なくともEmacs27.1のsrc/w32font.cでは LOGFONTのlfFaceNameメンバー変数を
locale-coding-systemに応じて変換している訳ですが、
恐らくどの国のWindowsでも utf8で格納される事は無い訳で。
逆に何故W系を使わないのか？ W系の方を使ってUTF16を固定的に
Emacs内で扱うコードに変換してしまえば locale依存はその後で吸収すれば良いハズで、
何故そうなっていないのか不思議には思ったりも。とは言え、
ASCII文字圏の人からすれば「おま国」でしかないかも知れませんが。
AM中に起床。
掃除したり洗濯したり。
東京都コロナ感染者。新規は116人。ちょっと上向いているか？
Emacsで游ゴシックにしたときにフレームサイズが大きくなる件。
M-x describe-font で調べてみたら sizeと heightがあり、
游ゴシックやメイリオでは sizeよりもheightが大きいという関係に
なっているようです。
もう少し調べてみると、例えば 游ゴシックと MeiryoKE_Consoleは
describe-fontでは以下のような感じになってました。
-----
name (opened by): -outline-\300\237\301\240\300\203S\300\203V\300\203b\300\203N-normal-normal-normal-mono-18-*-*-*-p-*-iso8859-1
full name: \237\340\203S\203V\203b\203N-9.0 ※化けてますけど游ゴシック
size: 18
height: 23
baseline-offset: 0
relative-compose: 0
default-ascent: 18
ascent: 18
descent: 5
average-width: 17
space-width: 17
max-width: 39
-----
name (opened by): -outline-MeiryoKe_Console-normal-normal-normal-mono-18-*-*-*-c-*-iso8859-1
full name: MeiryoKe_Console-9.0
size: 18
height: 18
baseline-offset: 0
relative-compose: 0
default-ascent: 15
ascent: 15
descent: 3
average-width: 9
space-width: 9
max-width: 51
name (opened by): -JY -游ゴシック-normal-normal-normal-*-18-*-*-*-*-0-iso10646-1
full name: 游ゴシック:pixelsize=18:foundry=JY :weight=normal:slant=normal:width=normal:scalable=true
file name: /home/TANE-HP/.fonts/YuGothM.ttc
size: 18
height: 20
baseline-offset: 0
relative-compose: 0
default-ascent: 0
ascent: 16
descent: 4
average-width: 9
space-width: 5
max-width: 5
name (opened by): -outline-游ゴシック-normal-normal-normal-mono-18-*-*-*-p-*-iso8859-1
full name: 游ゴシック-9.0
size: 18