昔の最近の出来事(2020.03)

2020/03/31

テレワーク。気持ち早めに終了。

あまりの眠さに急速停止。

2020/03/30

テレワーク。早くも無く遅くも無く終了。

志村けん死去。残念です.......

コロナ。感染経路不明のうち、夜の酒場で感染した疑いもある.....って、 やっぱ以前述べたようにやましい事があって 不明って事にしてんじゃん。それぞれの行動履歴が完璧でなくても、 何例か重ねてみれば補完できると思うのですがねぇ。そろそろ嘘付いても バレるくらいにはなっているんじゃなかろうか?

ESCとE/Jが交換できない件。Emacsでの誤打よりもEmacs外での誤打の方が被害 が大きかったです(^^; Excelとかで日本語と半角英数を切り替えるつもりで ESCキー(交換している場合はE/Jなのですが)を押してしまい、 入力がパーになるという。慣れるしか無いね。

2020/03/29

AM中に起床。

8:30頃外を見たら雪が舞ってた。そして外気が低すぎるせいか エアコンが霜取り運転モードになっている気も。 ところで「エアコン 暖かくならない」で検索してみると、故障だとか 部屋の広さに能力が合っていないとか、色々書かれているのですが霜取り運転 の事に触れているページはすぐに見当たりませんでした。 今年の初めにエアコンを交換した際、 電気屋さんには雪の降るくらい外気が低い時は運転が止まる事がある話を 聞いてたのですが、そういう時はかなり問い合わせがあると言ってました。 「しばらく待っててください」という回答をするしか無いと言ってましたが、 「寒いのにしばらく待つってどういう事だ?」という感じで直ぐに納得は してもらえないみたい(^^; エアコンの原理上しかたが無いのですが、 原理を知って使っている人はほとんど居ないという事なのでしょう。

そういや何かのTV番組で「エアコンで温度設定をしているのに何故 ボタンは冷房と暖房があるんだ?」 という事を言ってる人が居たのですが、他の人は何を言っているのか判らなかったのか 適当にあしらわれていました。確かに言われてみれば、例えば「27℃」って 目標温度を設定したのならば、現在温度から暖房を選択するべきか 冷房を選択するべきかは 判るんじゃないの?という気がしますが、 そうするとダメな理由があるんですかね?

「ひみつ×戦士 ファントミラージュ!」。え?二年目に突入するの!? 確かに映画公開が5月なので、公開より先に終わって次のシリーズが始まるって のは無いかとは思ったりも。

自粛要請と禁止。要請ですら買い溜め行動が起こるのに、禁止って言うと もっとダメになると思います。要請くらいで低空飛行する方が良いように思うのは 個人的な感想です。 海外では外出禁止となってる所も、食料や医薬品を買いに出るのは OKとなってるようです。ただし、政府からスーパー、コンビニ、 薬局、配送、....、ゴミ収集、下水管理 といった最終的に物が行きつく先まで 関係する人達に漏れなく働いてもらう事をお願いした上で 外出禁止にしないと、 簡単に物流は止まってしまうと思います。恐らく、それを完璧に把握している とは思えないし、思った以上に関係者は沢山居る(例えばスーパーの店員が出勤する のに公共交通機関を使うなら、そこは動かさなくてはならないとか)という事に なりそうなので、リカバリ不能に近い状況にならないと禁止にはできないのかも。 しかしながら、「桜並木を背景に酒瓶を持ちながら "どこまでは良いのか判断に困る"と言ってる人」 は確かにどうすりゃいいのかねぇ?とは思います。 いちいち罰則設けて禁止って言われないと判断も我慢もできないのかね? と思わなくはありません。

掃除したり。

REALFORCEで「ESCキー」と「E/Jキー」の交換を行う方法が無い件に関連して。 Emacsでの「M-なんとか」はWindowsだと「Altキーを押しながらなんとかキーを押す」か、 「ESCキーを押してからなんとかキーを押す」事で実行できます。 TANEは2ストローク押し派なので後者です。てか、「Altキー + x」は押しにくいです。 そして、global-set-keyで「\e\eなんとか」と設定した場合、「ESCを2回押してからなんとかキーを押す」 という割り当てができるのですが、Altキーは"押しながら"なので代用できません。 なんかもっと良い方法でESCキーを押す方法はないか?と思ったのですが、 そうだ「Ctrl+[」で「ESC」を押したのと同じゃないかと思い出しました(^^; うん、練習は必要だけど これに慣れればいいじゃないかという方向で。

「M-x (execute-extended-command)」を1ストロークバインドに割り当てるというのは どうだろう?と思ったりも。丁度「[?\C-,]」が空いてたので割り当ててみました。 それにしても、こんなベーシックなバインドをカスタマイズする事になろうとは(^^; いいけど。

2020/03/28

AM中に起床。

テレワークに使用するのはシンクラ端末なのでキーボードレイアウト変更が 不能になってます。CtrlとCapsを入れ替えられないと死ぬ体になっているので どうしたもんかと思ったり。で、思い出したのが 以前買ったREALFORCE。 指が痛いの対策に買ってみたのですが、Capsキー(Ctrlキーとして使用)に若干の 突っかかりがあり、指の痛いのは結局解消できなかったので使用していませんでした。 設定を眺めてみるとCtrlとCapsを入れ替えてキーボード内蔵のROMに記憶 できるというのが判り早速試したところ大丈夫そうだったり。ただ、「ESC」と「E/J(半角/全角の事)」 の入れ替えは対応していないようなので、しばらくの間はEmacsでの2ストローク押しの 「M-なんとか」は押し間違えるのだろうなという感じ。てか、CtrlとCapsの交換が行えるなら、 ESCとE/Jも交換可能じゃないの?とは思ったりも。過去機種にはDIPスイッチで ESCとE/J交換可能にしているものもあるので、そういう需要があるのも知っている んじゃないかと思うのですが。

久しぶりにREALFORCEを使ってみたのですが、なんかキーが固いという謎の感覚。 キーの動きが重いという感じでは無く、何故か指先に刺さるような痛みを感じる時 があります。肝心のCapsキー(Ctrlキーとして使う)の可動が悪かった為、スペーサーを 入れて(トラベル距離を減らす事で可動が悪いのに対応)、APCは一律1.5mm(一番浅い位置で反応) にして、かなり弱いキータッチをしているつもりなのですが何故かダメです。 キーの押し方に少し練習が必要かも知れません。

REALFORCE。キーが固いという感覚について、一つ気になった所があったので 意を決して対応。キーキャップなのですが、心なしか面取りが浅いというか 角が立っているように感じていました。そこで、 指で触ってなんだか角が立っている感じのするキーの角をヤスリで削って少し丸めて みました。まだ効果のほどとまでは言えないのですが、心なしかキーが固い 感じが無くなったような気も。キーキャップの角が立っていたのが 指先に刺さるような痛みに関係していたのかなぁ?判りませんが。

2020/03/27

遅めに帰着。

テレワーク令が出たので来週からテレワーク。やだなぁ.....

そういやこちらのサイト で都道府県別の感染者数マップを見る事ができるのですが、右側に出てる 症例一覧を見てると、東京とか大阪は年代や性別が不明なのは何故だろう と思ったりも。後から埋まるのか?

コロナ。結局、警戒を緩めると広がるという事だったようですな。 イタリアなんかも先週末の日本みたいな感じだったのかも?という事でなんとなく 納得。今増えているのは先週の3連休以前の分だと思われ。

そういやコロナに感染した野球選手が、においを感じないという症状があった というのをニュースで見たのですが、他の感染者の中にも同じような症状を 訴えている人がいるみたい。コロナとの因果関係が本当にあるのかは まだ判らないようですが、そういう事もあるらしい。 所で、先に述べた野球選手ですが、ニュースで見た所では「咳や熱症状は無いが 体調不良を訴えた。PCR検査を行ったら陽性だった」と言う事だったのですが、 咳や熱症状が無いのに何故PCR検査をするに至ったのかがよく判りませんでした。 コロナ感染するとにおいを感じない症状があるというのを知っていたのだろうか?

2020/03/26

早めに帰着。

あまりの眠さに急速停止。

2020/03/25

気持ち早めに帰着。

そういや本日でへっぽこページは20周年を迎えました。 毎度みてくださっている方々に感謝いたします。 20周年という事で特別に何かある訳ではありませんが これからもよろしくお願い致しますm(_'_)m

2020/03/24

遅めに帰着。

東京2020オリンピック延期。今の状況だと妥当と思われ。

コロナ。それにしても海外での広がり具合はなんなのだろう?と 思います。日本の様子を見ていると ちょっと警戒すればそんなに簡単に うつるように思えないのですが。それとも日本の状況が異常なのか?

最近報道とかで毎日流れている都道府県別感染者数ですが、海外から感染した 状態で帰国したケースは別カウントにして欲しいとは思ったりも。 海外で感染した人も合算してしまうと、あたかもその県で発生したか のように見えて紛らわしいと思います。「沢山居る」と見せかけて煽るのを 目的としているなら話は別ですが。
あと、ここ1週間くらいに陽性と判明した中で経路不明な人がいるってのも 本当かいな?とは思ったりも。 陽性判明した人も、高々 2週間よりも短い期間の行動範囲の話なのだから、 どんなに物忘れが激しくても、発症から遡った1週間程度の時間とその時に 居た大体の場所くらいは思い出せるだろとは思います。 今ならば 少なくとも東京都とかであれば100人以上の感染判明者が居る訳 ですから、大まかでも陽性反応が出ている人の行動履歴を何人か重ねれば交点が 見えるんじゃなかろうか? もし、本当にある時点から数日間前までの自分の行動履歴が思い出せない という場合、どんだけボンヤリ生活しているんだ?とは思います。 本当は判っているがやましい事があって嘘ついて「判らない」って事に してるのであれば話は別ですが。

2020/03/23

遅めに帰着。

あまりの眠さに急速停止。

2020/03/22

AM中に起床。

掃除したり洗濯したり。

さいたまスーパーアリーナでのK-1開催。どういう結果になったとしても リファレンスにはなるかも。

キャッシュフロー。現在、海外のインバウンド消費が激減しているので 観光事業は打撃を受けていると思いますが、日本ってそんなにインバウンド 依存してたんでしたっけ?とは思ったりも。さておき、その分を引いたと考えて イベント中止などによる損失はあるとは思いますが、イベントによる経済効果 ってそんなに大きいもんなんだっけ?とは思ったりも。一つのイベントの 損失額が庶民の桁感覚と違うので大きくは感じるのですが、実際に日本の経済が 揺らぐほどの物なのだろうか?と感じます。 外食産業はお客が減っているという事実はあると思いますが、 人間はゴハンを食べないと生きてはいけないので、食事のお金はどこか別の所を 流れているだけだと思うのです。という訳で、普段使いのお金は流れが少し 変わっただけ、特別使いのお金も いちいち遠くに行って使わなくても、 同額を近場やネット通販で使ってれば経済全体としては回っている事に ならないんですかね?

SNSにおけるデマ情報の拡散。なぜ簡単に広がるんでしょうね? ちょっと考えれば「んな訳 無いだろ?」と思うような物でも意外と広がり、 そしてなかなか消えないのが不思議に思う時はあります。

2020/03/21

AM中に起床。

コロナ。ヨーロッパでの広がり方はなんだか異常な感じがします。 挨拶のハグとかキスとかが要因の一つとも考えられているようですが、 そうだとするとインフルエンザなんかもすぐに蔓延するような感じなのだろうか? であれば、コロナに限らず一般的な感染症予防の意識が(習慣的な点も含めて) 低いという可能性も考えられるのでは?とは思ったりも。
インフルエンザは予防接種という手段がありますが、個人的には あれはあまり良くないと思う所があります。というのは、予防接種 そのものの効果の是非というよりは、「自分は予防接種を受けたから大丈夫 と言って手を洗わない」とか、そもそも広げないようにする意識が下がりそう だから。
とは言え、かかってしまった場合は仕方がないので 自己治癒能力で 回復するのを待つしか無いとは思いますが。

細菌と違ってウイルスは生物ではないとされる場合があります。 「細胞に取り付いて細胞の中で増殖する」と説明される場合があるので あたかも寄生生物かのような印象を受けるのですが、 触ると死ぬ毒(ウイルスの例え)に気づかず触ってしまっただけで、 決して毒の方から触って来る事は無いというのが個人的な解釈です。 ライフゲーム のようにウイルスの感染アルゴリズムを定義する事は可能だと思われます。

  1. 生物にウイルスが取り込まれると潜伏期間後にウイルスは増える。
  2. ウイルスを持った生物とウイルスを持たない生物が接触するとウイルスを持たない生物もウイルスを持つようになる(即ち感染の定義;感染のしやすさは別途パラメータが必要)。
  3. 生物の免疫力の方がウイルスの増殖よりも上回っている場合、時間とともにウイルスは減少する(結果、一定期間後に取り込まれたウイルスは消滅する事になる)。
  4. 生物の免疫力よりもウイルス増殖が上回り、一定のウイルス量に達すると生物は死ぬ(と定義する)。
  5. 生物免疫力よりもウイルス増殖が上回り、一定期間経ってもウイルスが消滅しない場合は生物は死ぬ(と定義する)。
  6. 生物が死ぬとその生物に取り込まれているウイルスも一定期間後に消滅する。
  7. ウイルスを取り込んだ後、3.に於いて免疫力の方が勝りウイルスを消滅させる事ができた生物は再感染しない。

他にも、それぞれの状態と遷移にはパラメータが必要かも知れません。例えば 生物内のウイルス量に応じて生物の動きが鈍くなるようなフィードバック要素なども あるかと思います。 さておき、このルールに従うと、例えば 「潜伏期間が短く、生物の免疫力を圧倒する増殖能力を持ち、すぐに消滅するウイルス」 であれば、ウイルスを取り込んだ生物は直ぐに死んでしまう為、取り込まれたウイルスも すぐに消滅するので広がりにくいといった感じになるかと思います。
「時間が経てばウイルスは弱毒化される」と言われていますが、前述ルールの 4.の条件を満たすような増殖力の非常に強いウイルスと、5.条件を満たすように 免疫力と均衡した増殖力の少し弱いウイルスがあった場合、4.のウイルスよりも 5.のウイルスの方が、アルゴリズム的に長く存在できると言えます。 なので、正確には「弱毒化される」のではなく「残っていくのは免疫力よりも少し弱いウイルス」 という事ではないかと考えます。
最近話題となっている「オーバーシュート(爆発的患者急増)」もパラメータを 調節すれば前述ルールで再現できるかと思います。ウイルスの潜伏期間を長めに設定して、 人の動きを止めなければ簡単に再現すると思います。なので、ここ数日感染者数が増えて いるとされる地域では人の移動を最小限にとどめ、またその地域の出入りもできるだけ 止めるのがこの感染アルゴリズムでの対応策の一つとして考えられます。 また、感染してても長距離移動しなければ広がらないというのはアルゴリズムからも自明と言えます。 感染しなければ良いという点では、距離を保つ(密集しない)とか手洗いなどの感染防止策により 「感染しやすさのパラメータを下げる」というのも対応策の一つと考えられると思います。 因みに「ロックダウン(都市封鎖や外出の禁止)」は完全に人の動きを止める事で 2.の感染条件を満たさないようにするという事になるかと思います。 ロックダウンはウイルスを持たない人の動きも止めてしまう訳ですが、 理論上は感染している人だけ動きを止めれば(隔離すれば)十分なハズです。 感染したら即症状が出るのならば比較的簡単に動きを止められると考えられるのですが、 潜伏期間が長いとその間の動き次第でうつってしまう確率が上がります。 症状が出る以外の方法で感染を検出する術が無ければ、感染している人だけ動きを止めるのは 事実上無理という事になります。

このようなウイルス感染アルゴリズムと生物の行動シミュレーションを合わせれば、 ウイルス投入後の広がりをある程度予測可能とは思います。しかし、 現在の人類の科学力では新しいウイルスの特性はすぐに判らないようなので、後からパラメータ 合わせをして感染状況の原因を後付けで想像する感じになるのかなぁ?とは思います。 もし、全員がスマホを持ってて位置情報をリアルタイムに収集できるとして、 それを後から参照可能なのであれば、発症した人の行動を過去に遡って 追跡する事で、機械的に感染源を特定する事が可能かも知れません。

ウイルスの振る舞いを別の物で例えられないか?と思っていたのですが 「火」が丁度良いのに気づきました。火力が強いと短時間で材料(生物)は燃やし尽くされ、 燃やし尽くすと火も消えてしまう。材料によって燃えやすい燃えにくいがあり、離れていれば 燃え広がらないなど、色々な点でぴったりハマるように思いました。

それにしても、このようなウイルスと生物の関係があるのは何故なのか?とは思います。 もしウイルスへの対策を意思を持って行わないとすれば、いずれグループの全員が感染し、 耐えられた個体だけが生き残るという感じになると思います。結果的に健康な個体だけに スクリーニングされるという訳です。今のコロナも、死亡率の高いのは高齢者という統計結果が ある訳ですが、感染拡大して沈静化したあとは健康な若者が残るので医療費が かからない未来がやってくるという皮肉な結果が考えられるかも知れません。

2020/03/20

AM中に起床。

Emacs27での改行文字のbackgroundプロパティが画面表示の右端まで埋められない件。 ewwでのプロパティ設定状況を見つつ、どの場合がイケてどの場合がイケてないのか 調べてみたり。すると、以下のような反応を示す感じみたい。

(let ((selected)
      (testbuffername "*test*"))
  (setq selected (selected-window))
  (switch-to-buffer-other-window testbuffername)
  (with-current-buffer (get-buffer-create testbuffername)
    (insert (propertize (format "%s\n" (version)) 'face '(:foreground "white" :background "blue" :extend t)))
    (insert (propertize (format "%s\n" (version)) 'face '((:foreground "red") (:background "yellow") (:extend t))))
    (insert (propertize (format "%s\n" (version)) 'face '((:foreground "yellow" :background "red") (:extend t))))
    (insert (propertize (format "%s\n" (version)) 'face '((:foreground "blue") (:background "gray" :extend t))))
    )
  (select-window selected)
  nil
  ) ; C-j

Emacs27 改行プロパティ テスト

この感じだと、:background と :extend は同じリストの中に入れておかなくてはダメそう。 ewwを弄ってうまく反応しなかったのは:backgroundと同じリストに入れられていないのが 原因だったようです。ただこれ、関数 add-text-properties とかで単純に足すと faceにリストとして足されるので、上の絵で言うと赤文字に黄背景 のケースにしかなりません。 なんとなくこうすればイケそうというのは判ったのですが、入れ子になっているリストの中の 一部に足そうとするとなんか 面倒臭くて(ELISPスキルが低すぎるとも言う)へにょる。 てかこれ、faceにadd-text-propertiesで足すだけじゃダメってのは面倒臭すぎるように 思うのですが。

以前、JPEG画像ファイルに含まれる Exifのパースに失敗して 画像が表示されないケースがあったのですが、gitのコミットの中に lisp/image/exif.elを修正するものがあったり。直っているかどうかは確かめていませんが 直っているかも知れません。しかし、画像ファイルと認識される以上は Exifにエラーが含まれていても無視して表示するで良いと個人的には思っています。

入れ子になったリストを単一リストに変換するコードを作ってプロパティを設定しなおす ようにしてみたのですが、なんだか 関数put-text-property の仕様が怪しいような。 この関数では開始位置と終了位置を指定するのですが、1文字分だけ指定したい場合は 開始位置と終了位置を同じにすれば良いのかと思った訳ですが、そうすると動いていない 動作になります。開始位置と(終了位置+1)を指定すると今度は2文字分に適用されていて、 一文字分だけ指定できるようになってなくね?と思った訳です。なんだこれ?

夕方頃に散髪にお出かけ。

入れ子になったリストを1次元にバラす関数を用意して改行文字に「:extend t」の プロパティを追加するようにしてみた所、どうにかそれらしい反応を得られたような気が。

--- lisp/net/eww.el.orig        2020-02-21 06:17:18.000000000 +0900
+++ lisp/net/eww.el     2020-03-20 18:36:56.722309700 +0900
@@ -532,6 +532,14 @@
                 (a . eww-tag-a)))))
        (erase-buffer)
        (shr-insert-document document)
+       (dotimes (n (point-max))
+         (goto-char n)
+         (if (eq (char-after n) 10)
+             (let ((buf))
+               (setq buf (eww-expand-list (get-text-property n 'face)))
+               (setq buf (append buf '(:extend t)))
+               (put-text-property n (+ n 1) 'face buf)
+           )))
        (cond
         (point
          (goto-char point))
@@ -550,6 +558,16 @@
            (forward-line 1)))))
       (eww-size-text-inputs))))

+(defun eww-expand-list (list)
+  (let ((l))
+    (dolist (e list)
+      (if (listp e)
+         (setq l (append l (eww-expand-list e)))
+       (setq l (append l (list e)))
+       ))
+    l
+    ))
+
 (defun eww-handle-link (dom)
   (let* ((rel (dom-attr dom 'rel))
         (href (dom-attr dom 'href))

Emacs27 eww extendプロパティ追加テスト

でも、箇条書きタグのインデントがうまく塗れていないような。これは元のewwがダメなので。 結果、色々と微妙。やっぱり誰か上手く直して!(^^;

2020/03/19

早めに帰着。

今頃ですが、以前作ったキーボードマクロの チートシートELISPの説明文が間違えていたので修正しました(^^; 御参考まで(kbm-cheat-sheet_200319.tar.xz)。

Emacs 27.0.90のeww。試しに:extendプロパティを追加するようにした後、 カーソル位置の文字のプロパティを調べてみると なんとなく「:extend t」を足せているようにも思うのですが、何故かうまく反応していない気が。

2020/03/18

早くも無く遅くも無く。

ewwのレンダリングの仕組みを調べてみたり。 どうやら、libxml-parse-html-region というC言語の組み込み関数で htmlのパースを行っていて、テキストへのレンダリングもこの関数で 行っているような感じみたい。テキストへのレンダリングはリンクなど のプロパティは設定されていない為、それは後で付加している感じみたい。 で、改行文字のテキストプロパティはlibxml-parse-html-regionの中で テキストにレンダリングされた時に決定されているようで、 「:extend t」を付加するには libxml-parse-html-region を弄るか、 テキストのレンダリング結果の改行文字に対してfaceのプロパティを 再設定して回る必要がありそうです。因みに、html内での例えばalignプロパティ は ewwで表示すると無視されている感じになってるのですが、 これも libxml-parse-html-region がalignを無視したレンダリング結果を 返しているからのようです。w3m並みにレンダリングしてくれれば、 もっと見た目を良くできそうな気も。ただ、こういう仕組みでは レンダリング結果を改善しようにも ELISPを弄って対応するのは 無理があるような気がしなくもありません。 逆に w3m & emacs-w3m が フルカラーターミナル対応できて、bgcolorや fgcolorなんかもhtmlに従った配色でレンダリングできるようならば、 こちらの方が見た目はずっと良いかも知れません。

2020/03/17

早くも無く遅くも無く。

Emacs27での改行文字のbackgroundプロパティが画面表示の右端まで埋められない件。 ewwで関係しそうな関数をあれこれ弄ってみるも所望の箇所が反応せず。なんで? もうこれは誰か直してくれるに違い無いと思う事にしよう(^^;;;

それにしても互換を維持するなら :extend を入れないと塗りつぶされない ようにするのではなく、noextendとか 塗りつぶしたく無いという意味の プロパティを追加するべきなのでは?とは思ったりも。 現時点で「:extend t」相当の動作をデフォルトとして書かれたELISPの 多さ(というかそれしか無かった訳ですが)から考えても、該当するELISPを 全てを書き換えろと言うのは無理があるように思えます。 迂闊な初期値変更で無駄な対応が必要になった 悪い例になっている気も。

2020/03/16

早くも無く遅くも無く。

Emacs27での改行文字のbackgroundプロパティが画面表示の右端まで埋められない件。 ewwで関係しそうな関数を少し弄ってみるも反応せず。あれぇ?

あまりの眠さに急速停止。

2020/03/15

AM中に起床。

掃除したり洗濯したり。

Emacs27での改行文字のbackgroundプロパティが画面表示の右端まで埋められない件。 ediff-buffersとかで差分の色付けをどうやって行っているのかを見たところ、 どうやらoverlayってのを使っているみたい。テキストデータとは別に指定した位置に 対してどのように表示するかを設定する仕組みのようです。 ただ、ちょっと試した感じでは改行の後ろを塗る事はできないような? after-stringというのを使って空白文字で画面の右端までを埋める事で塗るという 技はあるようですが、改行の後ろに空白文字を置く事はできないような動きに なっているように思います。しかし、ediff-buffers では改行の後ろを塗っている ような動きになっているようなのですが、どうやってるのかが判りません。 なんだこれ?

そういやmagitでもewwとかと同じく、改行の右側のbackgroundの塗りつぶしが 止められているので、表示の見た目がEmacs26.3と違っています。

ediff-buffersでoverlayをセットしていると思われる関数にデバッグ表示を 仕込んで、どういう指定をしているのか観察してみたり。でも、色付けを行う 範囲は改行含めた一行分を指定しているだけになっていて、改行の後ろを 塗る為に何かやっている感じは無かったり。うーむ?

もう少し良く見てみたところやり方判明。そして、overlayだけの話ではなく テキストプロパティの話だという事が判ったり。 先日のテストコードを次の様に変更してみました。

(let ((selected)
      (testbuffername "*test*"))
  (setq selected (selected-window))
  (switch-to-buffer-other-window testbuffername)
  (with-current-buffer (get-buffer-create testbuffername)
    (insert (propertize (format "%s\n" (version)) 'face '(:foreground "red" :background "blue" :extend t)))
    (insert-image (create-image "/usr/share/emacs/26.3/etc/images/splash.svg"))
    (insert (propertize "\n" 'face '(:foreground "red" :background "blue" :extend t)))
    (insert (propertize (format "%s\n" (version)) 'face '(:foreground "white" :background "red" :extend t)))
    (insert-image (create-image "/usr/share/emacs/26.3/etc/images/splash.svg"))
    (insert (propertize "\n" 'face '(:foreground "white" :background "red" :extend t)))
    )
  (select-window selected)
  nil
  ) ; C-j

テキストプロパティに「:extend t」というのを追加すると、Emacs 27.0.90でも改行文字から 画面の右端まで:backgroundなどのプロパティが適用されるようになりました。 探し方が悪いせいかextendについての情報を見つけられず。doc/lispref/display.texi の中に それっぽい記述があるのですが、infoからうまく見つけられずorz Emacs26.3では指定されていなさそうだったので、Emacs 27で追加される プロパティなのだろうか?

原因判明のきっかけとなったlisp/vc/ediff-init.elのgit logを見てみたところ、 以下のようなログが記されていたり。

7e238e7d50872d43a137c1350cb3b293aea176c2
Author:     Juri Linkov 
AuthorDate: Sat Oct 19 23:51:03 2019 +0300
Commit:     Juri Linkov 
CommitDate: Sat Oct 19 23:51:03 2019 +0300

Parent:     ab7db2814f * lisp/net/tramp.el (tramp-antispoof-regexp): Fix version.
Contained:  master
Follows:    emacs-26.1 (7943)

Add ':extend t' face attribute to diff faces (bug#37774)

* lisp/vc/diff-mode.el (diff-header, diff-file-header)
(diff-removed, diff-added): Add ':extend t' face attribute.

* lisp/vc/ediff-init.el (ediff-current-diff-A)
(ediff-current-diff-B, ediff-current-diff-C)
(ediff-current-diff-Ancestor, ediff-even-diff-A)
(ediff-even-diff-B, ediff-even-diff-C, ediff-even-diff-Ancestor)
(ediff-odd-diff-A, ediff-odd-diff-B, ediff-odd-diff-C)
(ediff-odd-diff-Ancestor): Add ':extend t' face attribute.

* lisp/vc/smerge-mode.el (smerge-upper, smerge-lower)
(smerge-base, smerge-markers): Add ':extend t' face attribute.

* lisp/vc/log-view.el (log-view-file, log-view-message):
Add ':extend t' face attribute.

* lisp/faces.el (secondary-selection): Add ':extend t' face attribute.
(line-number-major-tick, line-number-minor-tick):
Change :foreground to :background.


なんかこれ、ediffだけの話ではなくて ELISP全部見直しが必要な奴じゃね? とは思ったりも。

という訳で、ewwもbackgroundのプロパティを設定している所にextendを足してやれば 良いだろうと思って試してみたのですが、イマイチどこに足せば良いのかすぐ判らず。 なんてこと。てかこれ、知ってる人が見ればすぐ直せるんじゃなかろうか?

2020/03/14

昼前起床。

そういや最近のWebページではJavaScriptが動かないと内容が全く見られない ものもあります。JavaScriptを使う事で表現の幅が広がるとか沢山の利点がある のは判りますが、最終的に得られるものがテキストの文字列情報だったり、 単なる設定変更を行うだったりすると JavaScriptを挟むのは 面倒臭くね? とかいう事を、w3mでGoogleの検索設定を行うのに「ページあたりの表示件数」が 変更できなくなっていたのに気づいて思ってみたり。

Emacs27での改行文字のbackgroundプロパティが画面表示の右端まで埋められない件。 ediff-buffersで差分を表示すると、差分の色付けは行の左端から右端まで行われていた ので、何かやり方があるのか?と思って調べてみるも良く分からず。

2020/03/13

気持ち早めに帰着。

Web巡回して終了。

2020/03/12

早くも無く遅くも無く。

Emacs27での改行文字のbackgroundプロパティが画面表示の右端まで埋められない件。 ソースコードのどこらへんにあるかを調べてみるも まだ判らず。

ファイルコピーを行うcpコマンドに -sオプションというのがあるのを知ったり。 コピー元のファイルのシンボリックリンクをコピー先に生成するというものです。

$ ls -ltr
合計 0

$ ls -l ../
合計 328
drwxrwxr-x+ 1 TANE-HP none      0 3月  12 23:06 testdir
-rw-r--r--  1 TANE-HP none  20898 1月  28 17:50 w16select.c
-rw-r--r--  1 TANE-HP none  15127 1月  28 17:50 widget.c
-rw-r--r--  1 TANE-HP none 289639 3月   5 23:29 window.c

$ cp -s ../*.c .

$ ls -l
合計 3
lrwxrwxrwx 1 TANE-HP none 14 1月  28 17:50 w16select.c -> ../w16select.c
lrwxrwxrwx 1 TANE-HP none 11 1月  28 17:50 widget.c -> ../widget.c
lrwxrwxrwx 1 TANE-HP none 11 3月   5 23:29 window.c -> ../window.c

cpコマンドはUNIX系のシェルを使っていれば使わない場面は無いくらい 使っているのですが、こんなのいつからできるようになってたんだ?という感じです。 そんなに頻繁に使う場面は無いかも知れませんが、沢山のファイルを全て シンボリックリンクで生成したい場合に便利です。

そういやシンボリックリンクを生成する lnコマンドは複数のファイルを受け付けなかった よなぁ?と思ったのですが受け付けられるようになってたっぽい。あれぇ?

$ ls -l
合計 0

$ ls -l ../
合計 328
drwxrwxr-x+ 1 TANE-HP none      0 3月  12 23:21 testdir
-rw-r--r--  1 TANE-HP none  20898 1月  28 17:50 w16select.c
-rw-r--r--  1 TANE-HP none  15127 1月  28 17:50 widget.c
-rw-r--r--  1 TANE-HP none 289639 3月   5 23:29 window.c

$ ln -s ../*.c .

$ ls -l
合計 3
lrwxrwxrwx 1 TANE-HP none 14 3月  12 23:21 w16select.c -> ../w16select.c
lrwxrwxrwx 1 TANE-HP none 11 3月  12 23:21 widget.c -> ../widget.c
lrwxrwxrwx 1 TANE-HP none 11 3月  12 23:21 window.c -> ../window.c

ほぅ.....

Pouetの upcoming partiesのリスト からRevision 2020 が無くなっているのに気づいたり。 Webサイトを見てみると開催キャンセルのアナウンスが出てました (アナウンスページ)。 残念ですが今の状況から言えば至極真っ当な判断だと思います。

2020/03/11

遅めに帰着。

Web巡回して終了。

2020/03/10

遅めに帰着。

あまりの眠さに急速停止。

2020/03/09

本日お休み。AM中に起床。

ニュースを見ててまだマスク不足の話をしてるんだとは思ったりも。 経済産業省のページ にごちゃごちゃ書かれていますが、


結局、数字的にマスクが不足しているのは自明なのだから、供給量に見合う使い方や代替方法を もっと明確に広報するべきなように思えます。だって、所詮、普通のマスクでは ウイルス自体を防御できる訳ではないのだから、できるのはインフルエンザなどと同じく唾を 飛ばさないくらいの事しか無いと思うのですが。
あと、ワイドショー的なものでは、不足してるとか、転売されてるとか、政府がなんか ポーズを取ってるのを伝えるばかりで、「ハンカチとかで代用になるのか?」みたいな質問には、 専門家的なゲストを呼んでても、もにゃもにゃした回答しか得られないのはイマイチに 思えます。まぁ、専門家と呼ばれる人は「100% とは言えない」とか「ゼロではない」 みたいな言い方をするので、一般人には「で?結論としては何?」というのが 結局判らないってのはよくある事ですが。

ターミナルでのANSIエスケープコードによる表示制御について。 先日、どうも振る舞いが判らなかったのですが次のような感じみたい。


ANSIエスケープコードの詳細については こちらのWebエントリを 参考にさせていただきました。例えばprintfコマンドでの 「\e[41m」はWebエントリ内記述の「ESC[41m」 に対応します。 という訳で、ANSIエスケープコードではEmacs26.xのように改行文字で画面の右端まで 埋める動作を行っているのではなく、必要であれば右端までクリアする(==領域を埋める) 手順を追加しなくてはダメそう。

で、Emacs27.xではANSIエスケープコードのような行末表示対応が必要という事なのだろうか? と思ったのですが、そういう対応が必要だというのに気づいているのならば、 ewwもセットで修正されているに違い無いと思われ。そうなっていない所を見ると、 あまり考えずに文字表示の方を変更してしまったのではなかろうか?(そして 26.xと同じ結果を得る代替手段も用意されていない(?))とは思ったり。 実際の所どうなっているのだろう?という訳で、先日のような Emacs26とEmacs27との差が、 ソースコードのどの変更に連動しているのか?を少し調べてみたのですがよく判らず。

2020/03/08

AM中に起床。

最近、「ウイルスを除菌」という言い方に違和感を覚える。

Emacs 27.0.xのewwでbodyタグのbgcolor指定したhtmlファイルがうまく表示できない件。
ewwの問題というよりも改行文字の表示の問題と思われたり。次のようなELISPをスクラッチ バッファで実行してみたり。

(let ((selected)
      (testbuffername "*test*"))
  (setq selected (selected-window))
  (switch-to-buffer-other-window testbuffername)
  (with-current-buffer (get-buffer-create testbuffername)
    (insert (propertize (format "%s\n" (version)) 'face '(:foreground "red" :background "blue")))
    (insert-image (create-image "/usr/share/emacs/26.3/etc/images/splash.svg"))
    (insert (propertize "\n" 'face '(:foreground "red" :background "blue")))
    (insert (propertize (format "%s\n" (version)) 'face '(:foreground "white" :background "red")))
    (insert-image (create-image "/usr/share/emacs/26.3/etc/images/splash.svg"))
    (insert (propertize "\n" 'face '(:foreground "white" :background "red")))
    )
  (select-window selected)
  nil
  ) ; C-j

Emacs 26.3 と Emacs 27.0.90とでそれぞれ実行してみた結果が以下。

Emacs 26 vs 27 改行プロパティの違い(GUI)

Emacs26では改行文字のbackgroundプロパティにより、画面表示の右端まで埋められる感じになってますが、 Emacs27では改行文字に対応する1文字分だけにプロパティが反映されていて、 画面の端までは塗りつぶさない感じになっています。
改行文字の場合はEmacs 26のようになるのがあるべき仕様だと思われます。 でないと、ELISPアプリ側で いちいちターミナルの幅を調べて空白文字を 埋めるみたいな処理が必要になります。しかし、等幅フォントのTTYコンソール ならばそれでやりようがあるかも知れませんが、ピクセル単位の画像を1文字として表示したり、 プロポーショナルフォントを表示できるGUIスクリーンでは スクリーンの端までピッタリ空白で埋める事が原理的に不可能な場合があり得ます。 Emacs26でEmacs27風な結果を得る事は改行文字の前後でプロパティを細かく制御すれば ELISPアプリ側で比較的簡単に再現可能と思われます。ただ、多くの場合 Emacs27のようなレンダリング結果を期待するとは思えません。

そういや-nwでも同じ?と思い確認してみた結果は以下の通り。

Emacs 26 vs 27 改行プロパティの違い(-nw)

画像は表示できないので白の空白となってますが、基本的にはGUIと同じ ようにレンダリングされるようです。

シェルのコマンドラインからANSIエスケープコードで改行文字を 表示してみたのですが、これは挙動がよく判りません(^^;

Terminal ANSIエスケープコード

Ctrl-lでクリアした状態から表示すると改行文字はターミナルの右端まで塗りつぶさない ようなのですが、何度か実行してスクロールを伴う状態になるとターミナルの右端 まで塗りつぶすようになります。ただ、最初の「Hello World」後の改行は 塗りつぶされないのに、次の行のTestの改行は塗りつぶされます。 ナニコレ?訳が判らん。因みに、画像はCygwinのminttyでの表示ですが、TeraTermでも 同じようです。

2020/03/07

AM中に起床。

Emacs 27.0.xでExifパースが失敗して画像表示されない件。関数 image-toggle-display-image 内 の以下のコードでエラーしている模様。

    ;; Get the rotation data from the file, if any.
    (setq image-transform-rotation
          (or (exif-orientation
               (ignore-error exif-error
                 (exif-parse-buffer)))
              0.0))

ここだけ見ると判りませんが、image-toggle-display-imageの呼び出し元 ではcondition-case なるものを使って try catch 方式のエラーハンドリング を行っています。で、前述コード内の ignore-error はWebを検索しても出てこなくて (ignore-errors は例が沢山ある) ナニコレって感じですが、 エラーコンディションが exif-errorってシンボルだった場合は エラーを無視し、 そうでなければ (exif-parse-buffer)の結果を返すという ignore-errors の 特定ケース対応版って事みたい。 で、(exif-parse-buffer)はエラーしているのですが、exif-errorじゃない エラーだった為、無視されずに例外が発生しているという動きになっている ようです。

先日書いた通り、Exifが正しく入っているとも、正しくパースできているとも 想定できない可能性があるだろうから、何かしらエラーしてれば無視で良い んじゃない?という訳で、

$ diff -u lisp/image-mode.el.orig lisp/image-mode.el
--- lisp/image-mode.el.orig     2020-01-28 17:50:35.000000000 +0900
+++ lisp/image-mode.el  2020-03-07 10:44:03.872115000 +0900
@@ -769,7 +769,7 @@
     ;; Get the rotation data from the file, if any.
     (setq image-transform-rotation
           (or (exif-orientation
-               (ignore-error exif-error
+               (ignore-errors
                  (exif-parse-buffer)))
               0.0))

という事にしてみたり。もっとも、もしExifのパースにバグがあるのならば それを直すのが正しい方法なのでしょうけど、ファイル側がフォーマットに 従っていない場合は対応できません。また、元々のコードも exif-errorならば結局無視しているという事を鑑みるに、理由はどうあれ画像は 表示可能な訳ですから、Exifで如何なるエラーがあろうとも無視する方が 画像表示する目的を達成する意味では良いと考えられます。

以前から、ちょいちょいSystemプロセスが 全力(1CPU分)で動いて、その間Webページが開かないとか待たされる場合があります。 調べる方法は無いかとWebを検索してみたところ、 Process Expolorer で調べられる事が判ったり。これを使うと、Systemプロセス内のスレッド毎の CPU使用率が調べられる為、全く原因の見当が付かなかったのが「これかな?」と いう当たりが付く感じになりました。で、どうやらLANアダプタのドライバが関連 していそうという事が判ってみたり。CPU負荷が上がるとWeb表示が待たされると いう事から鑑みてもそうだろうと推測できるのと、 過去にREGZAのDLNAサーバ上の動画 を再生すると途中でネットワークが切れるという件を調べるのにネットワークアダプタ の設定を弄った記憶があります。元の値をメモらずに変更したので、何か悪さ しているのかも知れません。
因みに、大分前からNVIDIAのドライバを ダウンロードする場合は何故か600Mbpsとか出てて(その為 数秒でダウンロードが終わる)、 どういう仕組みなのだろう?と思っていたのですが、IIJのFTPサイト (ftp://ftp.iij.ad.jp/pub/) からLinuxのISOイメージとかをダウンロードしてみた場合も 700Mbps以上出る ようでした。単にサーバ側の送信性能によるものという気がしてみたりも。 で、大量にデータ転送すればCPU負荷が上がって一時停止する現象が再現するかと 思ったのですが、そういう訳では無く。再現方法が判れば ネットワークアダプタの設定を変えてみてどうなるか?ってのを試しやすくなるのですが.....

そういや、Emacs 27.0.x では「Package cl is deprecated」ってなってる (正確には強めにメッセージが出るようになった?)みたいですが、 結構あちこちで使われているような。て言うか、(require 'cl-lib) よりも (require 'cl) の方が圧倒的に多いような。

2020/03/06

早めに帰着。

先日のEmacs-27.0.90。-nwで起動した時に「C-s」が入らない件ですが、 どうやらscreenコマンドのあるプロセスのみC-sが入らないという 謎な状態になっていました。新しく起動したscreenコマンド上や、screen コマンドを使わない状態で起動すると問題無く「C-s」は認識されました。 てか、何故ピンポイントでこんな事が起きたのやら。という訳で、 Emacs本体に問題はありませんでしたm(_ _)m

そういやEmacs 27.0.50で画像判定に失敗するファイルがある件を調べていた ハズだったのですが、imagemagickを使ってビルドしてたり、26.3での imagemagick-types-inhibitが効かない件がバグってたのを見つけたり しているうちにそのままフェードアウトしてました(^^;
で、image.el内にあるファイルタイプを調べる関数を調べてみたのですが、 どれもjpeg画像と認識されてて問題無いようだったり。仕方ないので diredからファイル閲覧する関数 view-file の中を順に追いかけてみたり。 どうやら、関数 image-mode の中でエラー検出している所があり、 「Cannot display image: (sequencep 0)」となっているのが原因の模様。 何故エラーになるかはまだ判らず。

もう少し調べてみたところ、image-mode.el内の 関数 image-toggle-display-image の中に jpegファイル内のExif(Exchangeable image file format)から表示の回転角度を 取得する機能が追加されたようなのですが、回転情報取得に失敗しているのが表示 に失敗する直接の原因の模様。26.3ではExifを読み込む事はしていなかった (27.0.xでは image/exif.el というのが追加されてて image-mode.el 内でrequireしている) のでExif読み込みコードを外してみた所、エラーする事無く読み込めるようになりました。 Exifの何がマズいと判断しているのかは判らず。ですが、正しく入っていない かも知れない可能性もある事を想定すると、何か知らない感じだったら 無視する(Exif情報が無いものとする)方が良いんじゃないか?とは思ったりも。

2020/03/05

早めに帰着。

CygwinのMailingListアーカイブを見てたら、Emacsの27.0.90-1がテストバージョンで 配布されている模様。プリテスト版として27.0.90が 出た のに追従しているようです。27.1が来るのも時間の問題か?

ひとまずEmacs 27.0.50くらい(git pullしたので大体それくらい)のを元に パッチを作成して Emacs 27.0.90 をビルドしてみたり。ひとまず ビルドできてみました。少し試した感じでは、前ダメだったのはやっぱりダメな まま(gitでちょいちょいpullして変更ログは見てたのである程度は判ってましたけど) です。


27.0.50くらいの時には問題無かったのですが、27.0.90で何故かダメになってる物があるようです。

(後日追記:Emacs起動時に使用していたscreenコマンドの状態が原因だった模様。 Emacs本体には問題ありませんでした)

あと、日本語入力ELISPのAnthyでエラーするのもそのままなので、Anthyの 対応が必要なのも変わらず(以前の日記)。

このレベルのまま27.1でリリースしてしまうと、すぐに騒ぎになるかも?

2020/03/04

早めに帰着。

ちょろり調べ事。

2020/03/03

早めに帰着。

夕方のニュースでやってたポテトチップスを食べる手が汚れないように するグッズとか。......そんなに手が汚れるのがイヤなら箸で 食べれば良くね?

全然関係無い流れから、Wingdings/Webdingsというフォントの生い立ちを知ったり (参考)。ほぅ....

ELISPで構造体。構造体の宣言はグローバルなので、ありがちな名前 (例えばvertexとかpointとかcolorとか.....)を付けてしまうと簡単に 衝突してしまいそう。そこで安易に長い名前を付けてしまうと、今度は 参照するのが大変になります(^^; 結局、言語に組み込みのデータ型として 構造体を扱う訳ではないので、インスタンスから構造体型の推論を行う事が 原理的にできないという事なのでしょう。

2020/03/02

早めに帰着。

今更ですがEmacsのELISPで cl-lib(Common Lisp extensions) パッケージを使えば構造体を使える事を知ったり。 正確には、言語としてELISP自体に構造体というデータ型は無いので、 構造体っぽいデータを扱う感じになるようですが。 作りから考えると速度の方は期待できないと思われます。

あまりの眠さに急速停止。

2020/03/01

AM中に起床。

掃除したり洗濯したり。

ちょろりGTS。追加されたイベントを少し追加。

ちょろり考え事。まとまらず。


TOP PREV