最近の出来事

2024/11/05

テレワーク。早めに終了

clipsave。Officeスイートのツールでクリップボードに入れたデータは 32bitのDIBとして 得られるのですが、透明度がデタラメで変な表示になったり全面透明のPNG画像になるようだったり。 バグっているようなのですが判断する方法も無いので、オプションを追加して 24bitPNGでセーブ できるようにしてみました(clipsave_241105a.tar.xz)。 御参考まで。

2024/11/04

AM中に起床。

掃除したり洗濯したり。

先日のプログラムをもう少しだけ見直し。 こんなもんかなって感じになったので放流してみます (clipsave_241104a.tar.xz)。 コンパイルする必要があるので面倒くさいですが 興味がありましたら遊んでみてください。

一応、透明度付き画像のPNG保存にも対応しています。「Win+Shift+S」で非矩形切り出しした場合も Emacsでは よしなに表示されるようです。

画像貼り付けテスト on Emacs

これまで、ウインドウ画像のスナップショットを取るのに、

  1. ALT+PrintScreen で対象ウインドウ画像をクリップボードに保存する。
  2. GIMPを起動して、「編集→クリップボードから生成→画像」で貼り付け。
  3. 「ファイル→名前を付けてエクスポート→...」でPNGファイルに保存。

とやっていました。しかし、特に編集の必要が無いのであれば、clipsaveだけでPNGファイルに 保存できるので 随分らくちんになった気がします。

2024/11/03

AM中に起床。

クリップボードの画像データをPNGファイルにセーブするプログラムを作ってみたり。 実験をD言語で行なったのですが、実際に使うにあたって Cygwinファイルパスに相互変換するのが面倒くさいのと、 自前のD言語画像ライブラリは今回用事の無い画像フォーマット対応が含まれている為、 C言語で書き直して PNGセーブだけ行なえるようにしてみました。 一応、こちらの「Automatic screenshot insertion」 という org-mode でクリップボード画像をPNGセーブして orgの画像ファイル表示に 利用するローカルコマンドにも使える事を確認してみています。

エラーハンドリングを入れたりコマンドラインオプションを追加したりして整えてみたり。

2024/11/02

AM中に起床。

Win32APIでクリップボードのデータを取得する方法を調べたり。 フォーマットを検査するのにEnumClipboardFormats(0)を使ったところ、 0xc009や 0xc10bといった値が返ってくる場合があって これらが何なのかよく判らなかったり。 0xc009は例えばファイルエクスプローラで画像ファイルをCtrl-Cでコピーしたり Win+Shift+S でスクリーンショット画像をコピーした場合に返って来て、 0xc10bはブラウザで表示されたテキスト文字列をコピーした場合に返ってくるようです。 GetClipboardData()にフォーマットを指定して取り出せるようなので、 どのようなフォーマットで格納されているのかは関係が無いのかも知れませんが そういうものなのか?

2024/11/01

テレワーク。遅めに終了。

眠くて死亡。

2024/10/31

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

調べ事をして終了。

2024/10/30

テレワーク。遅めに終了。

タイピングplus。伸びない。

2024/10/29

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

Web巡回して終了。

2024/10/28

テレワーク。早めに終了。

以前、タイピングゲームの文章ってなぜか打ちにくいと記したのですが、 やっぱり独特の打ち難さがあるなぁと思ったり。 例えば「文章入力スピード認定試験 日本語」の 文章を入力してみると、あまり変な打ち間違いをしないように思えます。 例えば「どこで待ち合わせしようか」は なぜか打ち難いと思ったものの一つです。 「まちあわせ」は何気に左手に集中しているのと、個人的にあまり使わないのもあってか、 明らかに打つのが遅いと自覚できるし、何度やっても間違わずに打てません😓。

2024/10/27

AM中に起床。

掃除したり。

ちょろり投票にお出かけ。

emacs-develのアーカイブを 眺めていて、全然関係無い流れで現在の masterブランチに DirectWrite 対応したフォントレンダリングの サポートが入っているのを知ったり。ついに公式でもWindowsビルドでカラー絵文字が表示できるようになりそうです。

commit edf37e811cafa4092b13969613fa83f6e6d69ab3
Author: Cecilio Pardo <cpardo@imayhem.com>
Date:   2024-10-09 18:40:28 +0900

    Implement drawing text with DirectWrite on MS-Windows.

    This adds support for color fonts.
    * configure.ac: Add src/w32drite to W32_OBJ.
    * src/w32dwrite.c: New file.
:

因みに、拙作のカラー絵文字パッチとは何も関係はありません。 拙作のパッチは src/w32dwrite.cc というファイル名なのですが、 公式のは src/w32dwrite.c というファイル名のようです。まぁ、誰が付けてもこうなるかというファイル名 なのかも知れません。
さておき、描画全体を DirectWrite化するのではなく、文字描画だけを MemoryDCにレンダリングして BitBltでGDIに書き戻す方式です(拙作のと同じ)。アンダーライン描画や stipple描画はGDIで実現している 事を鑑みると仕方ない所かも知れません。という事は COLRv0での描画のみ対応で COLRv1での レンダリングは無しって事になりそうです。 拙作パッチはC++コンパイラを必要としていますが、公式の方は C言語のみで書かれているようです。 DirectWriteのヘッダ類を全部ローカルでC言語向けに再定義しているみたい。それもあってか描画本体よりも C言語向けのDirectWrite関係定義コードの方が圧倒的に多くなっているようです。
恐らくEmacs31系に入ると思いますので、一般に使えるようになるのは1年以上先と思われます(まだ30も出ていませんし)。 その頃になるとWindows10のサポートが終わっているので、Windows10の「Segoe UI Emoji」で表示される事は 無いかも知れません。

タイピングplus。これまで2回遭遇したことがありましたが討伐に失敗していた リトルドラゴンの討伐に成功したり。とは言え、マルチプレイのゲームなので他のプレイヤーの協力もあっての 事だとは思いますが。それにしても、これでレベルC ってことはこれ以上のボスはどういう事になるのだろうか? 装備で攻撃力が変わるようなので、タイピング速度が遅くても経験値(==練習量)で得られる&装備できる武器で、 タイピングの速い人と同じレベルで戦える.... という事なのかしら? そもそもタイピングが速い人は 素手(==装備無し)でとんでもないダメージを与えられるのかもしれませんが😅。 それにしても300kpmをちょっと超えるくらいの腕前で劇的に速くなったりしていないので、 これ以上はどうにもならんかも🥺。ランキングを見ると400kpm以上出せる人がかなり沢山居るようです。 こういうゲームなのでそういう人達が集まっているというのはあるかも知れませんが、 400kpmって秒間6.7キーを押すスピードなので普通の速度では無いとは思います。 先日記した REALFORCE TYPING CHAMPIONSIHP で1000kpm以上出てましたが、 秒間16.7キーを押すスピードなので、両手の指を使っているとはいえ 16連射以上の速度でキーを押している というのは尋常ではないとは思います。

Emacs-30.0.92がリリースされましたが、さっそく修正が入っているようです。 修正量にもよるかもしれませんが、もうあと一回は pretestを刻む可能性があるかも?

2024/10/26

AM中に起床。

Emacs30系のgitリポジトリをpullしてみたら30.0.92のタグが打たれていたり。 アナウンスはまだ出ていないようですが、アーカイブは置かれているようなのでダウンロードしてみました。 30.0.91のIME/他のパッチを当ててみた所、configureへのパッチだけがうまく当たらず。 仕方ないので ./autogen.sh 実行で対応。ビルドは成功。ちょろっと実行して使ってみた範囲では いきなりズッコケたりはしなさげ。次が出るまでテストしてみよう。
とかやっていたらアナウンスが出た模様 (Emacs 30.0.92 pretest is available)。

2024/10/25

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

調べ事して終了。

2024/10/24

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

そういえばEmacsのInfoの中にAntinewsてのが記されていますが、 これってバージョンが上がる度に毎回作文している人が居るってことだよなぁ?と思ったり。 誰が始めたのかは分かりませんが、メンテナンスを続けるのは面倒くさくはないのかなぁ? とは思ったりも。

2024/10/23

テレワーク。早めに終了。

MS-IME。数年前に知り、 以前にも現在のMS-IMEでは 「Shift単押しで英数/ローマ字の入力モードをトグルにする方法が無い」事を記したのですが、 意図的に半角英数混じりの長い文章を入れて一括変換したい場合に、英小文字始まりの単語を入れるのは ひと手間かかります。何より英小文字始まりの単語を主語とした文章はIMEエディタ上で書くことが原理的にできません。 「以前のバージョンのMS-IME」でも設定で意図的に有効にする必要がある機能だったので、知る人ぞ知る機能になっているのも イマイチなのかもしれません。 長い文章を変換した方が誤変換になる確率を下げる可能性があるのは間違いないと考えるのですが (今はできていないかも知れないですけど😅)、そもそも長い文章を入力することができないと意味が無いので、 それを妨げないようにならないのかと思う所です。
例えば「せまいはしのはしをあるくのはあぶない」の場合「狭い橋の端を歩くのは危ない」以外は 基本的には誤変換だと判断できるかと思いますが、「はしのはし」や「はし」を単漢字変換して 一発で意図した変換になるのを期待するのはまず無理だと考えられます。 また、日本語の文法の問題というのも考えられます。例えばSKKの説明でよく見る 「きょうはいしゃにいった」の場合、「は」が助詞か否かを判断すること自体が不可能と考えられます。 助詞「は」を省略しない文体で統一するのであれば、 「今日は歯医者に行った」と「今日は医者に行った」は一度学習すれば誤変換になりません。 また、「今日、歯医者に行った」であれば誤変換になりませんし、「今日は、医者に行った」も 誤変換になりません。という訳で入力方法という人間のやり方と 長文を解釈するという機械の力とで、 誤変換を減らす余地はまだあるのではないかと考えます。

2024/10/22

テレワーク。早めに終了。

タイピングplus。なにやらボス戦が続くなぁ?と思っていたのですが、 ソロプレイではなくてマルチプレイだというのに気づいたり😅。 また、ボス出現したばかりだと100万以上のダメージを時間内に与える必要があり、 時間当たりに与えられる平均ダメージから換算すると どう考えても無理だろ!?と思っていたのですが、 ボス討伐の通知で貢献度が示されていて マルチプレイなのかと判った感じ。 ただ、ボスの出現時刻が不明で、深夜に出現してしまうとプレイヤー人数的に 討伐不能になる事があるようです。

2024/10/21

テレワーク。早めに終了。

Webを散策していて「タイピングplus」という タイピング練習ツール(ゲーム)の存在を知りました。 どんなものか少し興味が湧いたのでアカウント登録してみたり。 まだゲームの流れが理解できてません😅。

そういえば、Emacsだと「M-x set-input-method」で「chinese-py」を指定すると中国語(簡体字)を 入力することができます。ふと、中国語の入力ってどれくらいの速度で行なえるものだろう? 思ったりも。chinese-py では 発音をローマ字入力的に入れると、漢字の候補が出てくる訳ですが、 候補があまりにもあり過ぎる上にそれを単漢字で選択しなくてはならない為、 入力に非常に時間がかかるように思ったからです。 少し調べてみた感じだと、予測変換を使うというのはあるみたい。 また、中国語のタイピングゲームもあるようですが、タイピング速度の話になると検索してもイマイチ それらしきものが見つけられず。日本語で検索しているからかも知れませんが。

2024/10/20

AM中に起床。

掃除したり洗濯したり。

そろそろ Emacs 30.0.91が出てから 1ヵ月経つので 30.0.92が出るかなぁ?と思ったりも。判りませんけど。 何気に 30.0.91以降に入っている変更量は多いなぁという気はします。 ドキュメント関連の修正が割合としては多いみたいですが。

2024/10/19

AM中に起床。

そういえば Webとかで遊べるのタイピングゲームの文章って何故か微妙に打ちにくいなぁ?と 思うことがあります。意図してそういう文章を選んでいるのだろうか?とは思ったりも。

2024/10/18

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

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

2024/10/17

テレワーク。遅めに終了。

Web巡回して終了。

2024/10/16

テレワーク。遅めに終了。

Webを散策していて、「タイピング練習広場」というサイトに 「超上級者への道」という ページがあるのを知ったり。 敢えてホームポジションを崩して打ちやすさを優先するという考え方がいくつか記されています。 「これ、速いかなぁ?」と思うものもありますが、「ひゅ」「ひょ」「にゃ」「にゅ」「にょ」の yを左人で打つというのは良いかもと思ったりも。b,h,yを左手と右手の両方で打ち分けるような場合、 セパレートタイプのキーボードでは無理だなと思う所です。
そういや以前、タイピングゲーム 「寿司打」のプレイ動画で、人さし指、中指、薬指で タイピングする事例を知ったのですが、ホームポジションを守ることは、 必ずしも速さと直結しない場合があるのも事実かも。

2024/10/15

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

Web巡回して終了。

2024/10/14

AM中に起床。

掃除したり洗濯したり。

Webを散策していて知った 「REALFORCE TYPING CHAMPIONSHIP 2024」の動画。 1000kpm以上とかおかしな速度(褒め)なのはさておき、かな入力で優勝とは。 ただ、今のところ 50音のほとんどをワンキーで入力可能な かな入力 に目に見えたアドバンデージがある 感じでは無さそうには思ったりも。濁音/半濁音/捨て仮名/アルファベット を入力する場合にローマ字入力よりも打鍵数が多くなる場合があるのも あまり差がない要因の一つと考えられます。 親指シフトキーボード、NICOLA規格キーボード、Dvorak配列 で、QWERTY配列+ローマ字入力を圧倒できるか? と言われると それは無い気もします。実際にどうかは分かりませんけれども。 しかしながら時間が経つほどに QWERTY配列+ローマ字入力 は最初から高みにあったのが明らかになっている気がします。
あとはフリック入力と比べたのも見てみたい気はします。「フリック入力の方が速い」みたいな話は、 結局慣れているから速いみたいなオチが付いていて、絶対的に速いか否かは分かりません。 理屈から言うと キーボードの かな入力 と同様に、濁音/半濁音/捨て仮名/アルファベット が混在すると タイプ数は増えるのと、あ段以外はスライドが必要、Nキーロールオーバー的な入力はできない と鑑みると、どんなに頑張っても キーボードの かな入力 より速くはならないのではないか と考えます。 でも、実際にどうなのかは分かりませんので、 同じ対戦タイピングシステムで入力方式無差別の頂上対決を見てみたいところです。

少し前にInkscapeの 1.4はまだ出ていないと 記したのですが出た模様。ちょろっと使ってみた感じは大きく変わったようには感じなかったりも。 ただ、絵文字のレンダリングがモノクロ(カラーではない)&上の方が見切れるのは1.3系から変わらず。

何故か今まで気づかなかったのですが、GIMPのRecent Newsに 10月5日付けでリリース候補のアナウンスが出ていたり。3.0RC1が出るまでにはまだ少し時間がかかりそうです。

2024/10/13

昼頃起床。寝すぎ。

シャングリラフロンティアのアニメ。 よく考えてみたら、架空のゲームのプレイ動画の アニメって事だよな?と思ったりも。 エムルなどのNPCのAIが強力過ぎてゲームという設定を忘れてしまいます。 実際のゲームでプログラムした以上の事を AIが勝手に喋ってしまうとネタバレして 収拾がつかない事態になりそうですが😅。

2024/10/12

AM中に起床。

ちょろりお出かけ。確かここに郵便ポストがあったハズだが....と思ったのですが いつの間にか無くなっていたり。 その次に知っている場所は大分遠いのだけど仕方なし。それにしても郵便ポストって無くなる物なのだっけ?

Emacs30系ブランチのリポジトリで、chart.elというELISPの更新が入っていたのですが、 これって何?と思ったり。29.4には一応入っているようですが Infoの説明は無いようです。 こういうこと ができるアプリらしい。ほぅ....。git log 上は2009年9月28日に初回コミットされたものらしく、 随分前から存在していたようです。

大山のぶ代氏 逝去。90歳でしたか。 随分前に アルカノイドが上手いというのを知ったのですが、 Wikipediaに 自身の別荘に筐体を所有していた話とか、その筐体が ゲーセンミカド で現在も稼働している事が 記されています。

2024/10/11

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

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

2024/10/10

テレワーク。遅めに終了。

ちょろり調べ事。

2024/10/09

テレワーク。遅めに終了。

ちょろりコーディング。

2024/10/08

テレワーク。遅めに終了。

ちょろり調べ事。

2024/10/07

テレワーク。遅めに終了。

Web巡回して終了。

2024/10/06

昼前起床。

掃除したり。

日本語入力での漢字変換。多少の誤変換があったとしても、入力に専念して変換キーを一切押さずに自動変換&自動確定 に任せるとどうなるか?と思ったり。 で、試してみたのですが、ある程度の誤変換は許容する前提でも MS-IMEの場合はちょっと具合の悪い所があります。 以前にも記したことがありますが、 MS-IMEでは変換せずに入力を続けていると、ある長さを超えた所で自動的に変換確定します。 しかし「ある長さ」はIMEのメモリバッファの長さのため、例えば「じどうしゃ」という単語の 途中にメモリバッファの区切りが重なってしまうと「じどう」と「しゃ」に分かれてしまった場合には、 「じどう」も「しゃ」も誤変換になる確率が高くなってしまいます。 「じどうしゃ」で変換すれば ほぼ誤変換になることは無い場合でも、連想できない区切りで変換しているがために 意図した変換にならない場合があるという感じです。 ただ、バッファの区切りがうまく句読点に乗ればかなり変換精度は高いように思うので、 そこんところを改善すれば、変換効率を下げる事無く 変換キーを押す頻度を減らすことができるため (入力をやめるときに押すだけになる)、入力速度がかなり上がるように思います。

2024/10/05

AM中に起床。

そういえばInkscapeの 1.4はまだ出ていないなと思ったり。 5月にスクリーンコンテストの結果が出たので、夏ころには出るかと思っていました。

Gboard 両面バージョン」。 以前、棒バージョン ってのがありましたが、今回のも冗談が過ぎる😅。

2024/10/04

テレワーク。遅めに終了。

眠くて死亡。

2024/10/03

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

Web巡回して終了。

2024/10/02

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

flymake。リモートファイルのmakeも動くことは動くのですが、ちょいちょいエラーが出たり そのエラーが原因で 生成された一時ファイルが残骸として残ったりと、イマイチな感じを整えられず。 一旦放置。

何気に「UDEV Gothic」のページを見たら、 8月に v2.0.0 てのがリリースされていたのを知ったり。 以前、存在を知った時に 全角空白文字の可視化グリフは無い方が良いと記したのですが、v2.0.0では 全角空白文字の可視化グリフ無しの バージョンが用意されています。

2024/10/01

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

flymake。ローカルのファイルだと特に問題無さげなのですが、リモートだと何やらエラーメッセージが 出るのですが、誰がどういう理由で出しているのかがよく判らず。 カスタム変数flymake-no-changes-timeout を 0.5 から 1.0 に増やすと大丈夫そうになったり。 非同期実行とTRAMP転送が何かしらぶつかっているのか?🤔

2024/09/30

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

flymake。まだちょっと怪しい所があるのですが、リモートでmake実行した結果をエラー表示できるようになったり。 一時ファイルに保存したコードをチェックするので多少の突っかかりはありますが、まぁイケるかなという感じ。

そいえば、flymakeのテストはD言語で特に意味の無いコードを書いてわざとエラーさせたりしながら 実験していたのですが、gcc 14.2ベースの gdcだと やたらエラーメッセージが出るなぁ? と思ったりも。セミコロンが抜けているだけでも色んな所がエラー指摘されるのはなんでだ?🤔

2024/09/29

AM中に起床。

ちょろりお出かけ。リロードしたら新一万円札が数枚混ざっていたり。 連番だったので、もしかすると以降は新一万円札しか出てこないATMになっていたのかも。

flymake。弄っているうちに動きが変になったり。関数unwind-protect のbody-formの 位置を間違えてたのが原因だった模様。if もそうなのですが、デバッグメッセージを 出すようにするとき、油断するとprognやletでブロックを形成し忘れていて、 メッセージは出るけど動きが変ってなってしまいます。

(let ((condition t))
  (if condition
      (func1)
    ))

↓↓↓message出力を足しただけのつもりが.....

(let ((condition t))
  (if condition
      (message "msg")
      (func1)
    ))

前述の例だと文法的にもエラーにはならないので大抵すぐに気づきません。修行が足りません😓。

2024/09/28

AM中に起床。

flymake。flymakeの infoに記された make向けのサンプルコードを参考に 動きを調べているのですが、なんとなく仕組みが判ってきたようなそうでも無いような。 ruby向けのサンプルでは Makefile無しの代わりに バッファの内容を syntax check実行モードで 起動したrubyプロセスの標準入力に流し込んで、得られたエラーメッセージをパースして 元のソースコードのバッファにチェック結果を反映するという仕組みのようです。 flymake的には一時ファイルを生成するか否かは外出しの関数次第のようなので、 リモートで実行するか否かを考慮してファイルパスなどは加工する必要があるみたい。
どのような言語でも makeを介して コンパイラなりインタプリタなりLintなりを実行し、 得られた結果文字列をパースすれば こんなに面倒な事にならない気も。 makeを使う ひと手間をサボると面倒臭い事になるようには思ったりも。

2024/09/27

テレワーク。遅めに終了。

実験。うーむ、わからん。

2024/09/26

テレワーク。遅めに終了。

調べ事。

2024/09/25

テレワーク。遅めに終了。

ちょろり調べ事。

2024/09/24

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

Emacsのinfoでflymakeを調べると、Flymakeとして独立したinfoページにリンクがあるのを知りました。 中に ruby-flymake.el というサンプルコードが載っていて、 flymake-proc.el 内の 関数flymake-proc-legacy-flymake を ruby向けに実装するような感じのが記されているようです。 因みに ruby-flymake.el は lispディレクトリには存在しないもののようです。なんで?🤔 さておき、これをテンプレにして考えろって事なのか?と思ったりも。敷居が高い.....

2024/09/23

AM中に起床。

掃除したり。

リモートディレクトリのflymake。 何やらエラーしているのですが、どこを見てエラーと言っているのかがよく判らず。 前からそうなのですが、flymakeは実行した結果がどこにも出ないので、 見れば原因が判るようなエラーメッセージも見る事ができず、何が悪いのかがさっぱり判りません。 その後も弄ってみたのですが調べ方の要領が得られず挫折気味🥺

2024/09/22

AM中に起床。

リモートディレクトリのflymake。 一つは makeのオプション -C で実行するディレクトリを指定しているのですが、 これが tramp-file-name(/method:user@host:/pathto/) になっているというのがありました。 もしかしてこれを最後のパス指定に変えれば動くのか?と思って試してみたのですが、 make-processではやっぱりダメそう。

26.3時代のmake-processではリモート実行はできないようで、 リモートディレクトリでプロセスを実行したければstart-file-processを使用しなくては ならなかったようですが、27.1から :file-handler というキーワードを使えばリモート実行が できるようになっているもよう。で、少なくとも Emacs30の flymake-proc.el 内 関数flymake-proc-legacy-flymake で実行している make-process実行では :file-handler は 指定されていませんでした。先の make の -Cオプションの指定を適当にごまかして make-process に「:file-handler t」を指定してみたのですが、なにやらよく判らない挙動になったり😓。 うまくいきません。

「:file-handler t」を入れない時は「make ....」をローカルで実行していてエラーという感じだったのですが、 「:file-handler t」を追加すると、何故か「/bin/sh -i」というコマンドを実行しているようで、 エラーの原因が違っています。どういうこと?🤔 もう少し調べてみると、エラーはしているのですが、 リモートでshは実行されているようで、現状は実行してエラーする度に shのプロセスが終了せずに 増え続けているという状況でした。-iなのでインタラクティブシェルとして起動されているようですが、 終了せずに留まり続けられるのだっけ?🤔

2024/09/21

AM中に起床。

EmacsのTRAMPを使ってリモートのVMやその中で動いている コンテナの中のファイルを編集する事ができます。 リモートディレクトリのdiredバッファや、リモートのファイルを開いているバッファで「M-x shell」を実行すると、 何気にリモートで実行されたshell(つまりsshログインやコンテナ execした状態)のターミナルになるのを知りました。 因みに、カスタム変数 explicit-shell-file-name の設定に bash.exeって書いてあったせいで起動できなかったのですが、 拡張子を削ってOKになりました。
で、flymakeもリモートでmake実行できないのだっけ?🤔と思ったり。 以前、リモートのpythonソースファイルをflake8でチェックできる というのを知った訳ですが、リモートファイルをパイプでローカルのflake8に食わせるという方法でした。 単一ファイルの場合はそれでも良いのですが、makeを使うようなプロジェクトだと、 ソースファイルだけがリモートにあって、ローカルのmakeやコンパイラを使ってチェックするという事は あり得ません。単純にリモートで make実行したコンパイル結果を flymakeのエラー表示などに使うように 考えれば良いと思われます。で、M-x shellでリモートシェルが起動できるという事は、makeコマンド も同じように実行すれば良い(事前にflymake用の 一時編集中のファイルを書き出す必要はあるかも知れませんが)ハズで、 M-x shellでここまでできているのなら、flymakeで実行するコマンドもリモート実行できる状況にあるんじゃないのか? と思った次第です。ただ、どうにも flymakeと TRAMPを組み合わせた例がWebで見当たらず。 できないけどそのような使い方をする場面が無いので誰も困っていないのか、 実は特別な事をしなくても(TANEの設定がマズいだけで)出来るので誰も困っていないのかはよく判りません😓。 少し調べてみるか....

そういえば、Emacs30では 何故か.emacsに「(require 'flymake-proc)」を追加する必要があるようなのですが (以前のメモ)、flymakeの下請けにflymake-procがあるのだと 勝手に思っていたのですが、どうやら flymake-procの下請けが flymakeのようだったり。 Emacs29.4では flymakeの中(何故か最後の行)で「(require 'flymake-proc)」が記されているのですが、 Emacs30ではその行が無くなっているようです。flymake-procでは Emacs29.4もEmacs30も 「(require 'flymake)」が含まれているので、設定的には「(require 'flymake-proc)」の方が 必要という関係になっているようです。ただ「そうなんだっけ?🤔」感は拭えません。
で、flymakeでのチェックプロセスの実行は flymake-proc.el内の 関数flymake-proc-legacy-flymake で行なわれているようですが、make-processでプロセス実行されるみたい。 かつては flymake.el内で、start-file-process を使ってリモートでコマンド実行するようになっていた ようですが、2017年8月17日のコミット fe9dc7a08 で現在のflymake.elとflymake-proc.elに 分離されたようです。そのすぐ後の 2017年8月23日のコミット 6954270e8 で start-file-process を使っていたのが make-process に変えられて、今に至るという感じみたいです。 ぶっちゃけ、ここで(ローカルでしか動かないように)ぶっ壊してるんじゃ?と思わなくもありません。

2024/09/20

テレワーク。遅めに終了。

調べ事をして終了。

2024/09/19

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

Emacsのmasterブランチ(31系)に src/w32.cと src/w32fns.cというコードで ctype.hの代わりに c-ctype.hというヘッダを使うようになり、例えば 関数isalpha() を c_isalpha() に置き換えるという変更が加えられているようです。 c-ctype.hって何?ってのがよく判らないってのもあるのですが、 src/w32fns.cは Cygwinでも使用しているので コンパイルが通らなくなるような気がしたりも。

もう少しWeb検索してみると c-ctype.h は「Gnulib」 由来のヘッダらしい。てかこれ、現状で ctype.hの関数で動いているものを わざわざ c-ctype.hの関数に置き換えるメリットって何だ?🤔 とは思ったりも。 もう少し git logを辿ってみたところ、色んな所で c-ctype.h に変更しているみたい。 どうやらマルチバイト文字に対応するという理由があるみたいです。

2024/09/18

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

調べ事をして終了。

2024/09/17

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

Unicode16.0。今回は追加される絵文字の数は少ない気が。 なぜこれらを絵文字に定義しようと思ったのかはよく判りませんが。 そういや、まぁまぁな数のヒエログリフが追加されるらしいのですが、 こちらは絵文字ではないので 例えば「Noto Sans Egyptian Hieroglyphs」 とかで対応されたフォントをインストールすれば表示可能になると思われ。 因みに、先週末に Emacsのmasterブランチ(31系)に Unicode16.0対応が入ったようです。

2024/09/16

AM中に起床。

掃除したり。

そういえば、Emacsの find-dired/find-name-diredでリモートマシンのファイル名に空白が含まれていたり マルチバイト文字を使っていた場合に クオートされた表示になるのですが、それだとファイル名を選択しても そんなファイルは無いと怒られてしまいます。 ローカルファイルだとクオートはされていないので、関数start-file-process-shell-command で返ってくる結果文字列がクオートされているところから、何かしらリモートプロセス実行した際に どこかでクオートされているのかしら?と思ったり。

ls の manを見てみたらクオートするか否かをコントロールするオプションがあるのを知りました。 utf-8でリモートのlsが文字列を返してきて、バッファのコーディングシステムがutf-8という前提であれば、 カスタム変数find-ls-option を

(setq find-ls-option
      '("-exec ls -ldN --show-control-chars --time-style=long-iso --group-directories-first {} +" .
        "-ldN --show-control-chars --time-style=long-iso --group-directories-first"))

てな感じに設定すればイケました。 lsのオプション「-N, --literal」はクオートせずに表示するというオプションなのですが、 これだけだと自動的に「-q, --hide-control-chars」が付与されるようで マルチバイト文字が 文字「?」に 置き換えられてしまう為、「--show-control-chars」を合わせて指定する事で そのまま無加工で表示されるようです。 クオートがlsの機能だとは思いもよりませんでしたが、find-dired.el内でもそのことには触れられてはいないようなので、 環境依存文字を使用する場合の辻褄合わせは自分でなんとかしろって感じなのかも知れません。

2024/09/15

AM中に起床。

以前、Emacsのfind-diredのlsオプションに --group-directories-first を指定しても効いていないなぁ?と思ってそのままになっていました。 おもむろに調べてみた所、findの実行結果をEmacs側でソートし直しているのが判りました。 カスタム変数 find-dired-refine-function を nilに設定すれば find+lsの実行結果が 加工されなくなるので --group-directories-first が効いたように表示されます。 しかし、findで見つかる ファイル/ディレクトリ の数が多すぎる(lsに渡す引数が長すぎる)と、 find側の方で自動的に何回かに分けて lsが実行されているようです。 このため、分割実行毎にディレクトリがまとまるけど、全てのディレクトリが最初の方にまとまらない 場合があるという事になるようです。 例えば、Emacsのソースの最上位ディレクトリ下で、「M-x find-name-dired」のワイルドカードを「*」とか にして全ディレクトリ/全ファイルを表示しようとすると ダメな場合があるという感じです。 なんかうまくいかない🥺。 でも、実際にfindしたいのはファイルの方が多いと思いますので、実用上は問題にはならないかも知れません。 という訳で、しばらくfind-dired-refine-functionを nilに設定して使ってみよう。

以前、「結合文字の濁点」と言うものがあるのを知ったのですが、 Emacsでたまたま設定していたフォントで表示するとなんか違う感じに思ったり。 どうやらフォントによって上手く表示される場合とされない場合があるのが判りました。

U+3099/U+309a 濁点半濁点表示テスト on Emacs

「源ノ角ゴシック」はうまく表示されていますが、「Noto Sans Mono CJK JP Regular」は半濁点が微妙です。 「源ノ角ゴシック」がルーツとなっている「HackGen」は半濁点がイマイチです。 意外に思ったのは「BIZ UDゴシック」がダメらしい所。 BIZ UDゴシックがダメなのに関係あるのかは判りませんが、 「UDEV Gothic JPDOC」は何故かあ行の濁点/半濁点が微妙な感じです。 BIZ UDゴシック以外の Microsoftのフォントは何気にイケてます。 普段使いは「MeiryoKe_Console」なのですが、こちらもメイリオが元になっている為かイケてます。 改めて比べてみると 普通にイケるのは実はスゴイ事なのかもと思ったりも。

本当に「BIZ UDゴシック」でダメなんだっけ?と思い、最近のEdgeでは等幅フォントに 「BIZ UDゴシック」が設定されている(以前のメモ)ので 確認してみたところ、

あ゙い゙ゔえ゙お゙あ゚い゚う゚え゚お゚
がぎぐげごか゚き゚く゚け゚こ゚

豆腐にならずに表示できてそうな気がします。Emacsの問題なのか?🤔
拡大して観察してみたところ、
あ゙い゙ゔえ゙お゙あ゚い゚う゚え゚お゚
あいうえおあいうえお  ←濁点/半濁点無し

がぎぐげごか゚き゚く゚け゚こ゚
かきくけこかきくけこ  ←濁点/半濁点無し

「あ゙い゙ゔえ゙お゙」のうち、「ゔ」以外はメイリオが代用されているように思ったりも。 因みにChromeだと 我が家では Noto Sans CJK JP が標準フォントになっている(以前のメモ)為か、 Noto Sans CJK JP が代用されているようです。 ともかく、「結合文字の濁点」を 編集するにしろ表示するにしろ やっぱり事故しか起こらない気がします。

Unicode正規化」 というWikipediaによると、先の濁点を分解するか合成するかみたいな変換をUnicode正規化って言うらしく、 NFD(Normalization Form Canonical Decomposition)とかNFC(Normalization Form Canonical Composition)とか あるらしい。で、Emacsのコマンドの中に、 ucs-normalize-HFS-NFC-region 、 ucs-normalize-HFS-NFD-region 、 ucs-normalize-NFC-region 、 ucs-normalize-NFD-region 、 ucs-normalize-NFKC-region 、 ucs-normalize-NFKD-region といったリージョン文字列をUnicode正規化操作するものがあるのを知りました。 例えばNFDな「がぎぐげご」を 「M-x ucs-normalize-NFC-region」で変換すると、合成されて NFCな「がぎぐげご」に変換できるようです。HFS-NFCやHFS-NFDはWikipediaに記された macOSのファイルシステムで NFDの変種が用いられているってのに対応しているものと思われます。 因みにヘルプを見ると 23.2から実装されているようです。ほぅ...

2024/09/14

AM中に起床。

エアコンの水漏れ対策その後。大丈夫そうなので 避けていたTV台などを元の位置を戻したり。

Windows11で Emacs 30.0.91のテスト。の前に Windows10のPCで AVIF対応とかEmacs以外で色々弄っていたのを反映したり。 反映後に 30.0.91をビルドして起動。大丈夫そう。 Unicode15.1の絵文字は Windows11じゃないと 確認できないので地味に面倒臭いです。
そういえば全く気にしていなかったのですが、emacsの実行ファイルって stripしないと130MBくらい あるなぁと思ったり。stripすると 8MBくらいになるので大分色々シンボルが付いているという感じかも。

そういえば、以前 D言語でも 多重ループを脱出する のに ラベルドステートメントが使えるのを知ったのですが、自作の d-ts-modeで何気に試すと インデントができないなぁというのに気づいたり。対応してなかったっけ? 毎度 tree-sitterのインデント対応はどう書けばよいのか判らないので、こうか?と思い 適当に試したところ、それっぽい感じにはなった気が。ただし d-modeとちょっと違う感じなのが イマイチな気も。
ところで、誰かもっと良いd-ts-modeを作っていたりしないだろうか?と思って検索してみたのですが 見当たらず。

2024/09/13

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

libjxlの v0.11.0がリリースされているらしい。

Emacs 30.0.91。IMEその他のパッチを少し見直したり。
いつもの感じでイケば 1ヵ月毎に 30.0.93くらいまでプリテストがリリースされて、 年末か遅くても来年の初めには30.1がリリースされる感じになるのかなと思われます。

2024/09/12

テレワーク。遅めに終了。

昨日 Emacs 30.0.90 の話を記したのですが、30.0.90では問題があったらしく、 Emacs 30.0.91 でリリースされた模様(Emacs 30.0.91 pretest is available)。

早速、手元の 30.0.60(のあるタイミング版)から作ったパッチを 30.0.91 に当ててみたり。リジェクト無しで当たり、 ちょろっと使った感じでは特に問題は無さげ。 ただ、以前対応した admin/unidata/emoji-zwj.awk スクリプトは パッチで新しくなってもそれを使ってデータを再生成しないので、予め admin/unidata の下で「make clean && make」とかしてから emacs本体の方を makeする必要があります。 という訳でしばらくテストしてみよう。

2024/09/11

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

エアコンの水漏れ対策その後。今のところ水漏れは無し。

先日、Emacs30系ブランチで バージョンが 30.0.90 になってるらしいと記したのですが、 偶然にも emacs-30.0.90ってタグが打たれたコミットが行なわれたみたい。 でも、そのすぐ後に(不足していた?)configure.acのバージョン番号追従のコミットが入ったりしていて、 アーカイブにするにはまだ準備が整っていない状態なのか?という気がしたりも。

2024/09/10

テレワーク。早めに終了。

エアコンの水漏れ対応で電気屋さんに診てもらったり。 ドレンパンにゴミでも詰まっているのかと思ったのですが そうでもないっぽい。 ひとまず室内機のクリーニングを実施する事なったのですが、作業を見てたけどなかなかに面倒臭い。 でも本体奥に見えるファン(ラインフローファンとかクロスフローファンと呼ぶらしい)に引っかかっていた ホコリが綺麗に除去されました。ドレンパンとかも一通り掃除して完了。 数日様子を見る事になりましたが果たして....。 因みに、掃除前に冷房運転していたのですが 今日は水が溢れる事は無く。 おとといや昨日に比べて今日は冷却が追い付かないような気温ではなかった為か?

そういや、以前 Cygwinビルドで harfbuzzの DLLがロードできていない件 が修正されたとき、Cygwinじゃ無い場合のコードが壊れているんじゃないか?と記したのですが、 修正された模様。

ところで Emacs30 は 30.0.90 ってバージョンにいつの間にか上がっているようですが、 ソースアーカイブってリリースされないんだっけ? いつも x.y.90代のアーカイブがいつの間にか pretestの置き場に置かれていて アナウンスあったっけ?ってなるのですが、30.0.90は置き場にアーカイブが無く、 アナウンスもされていないように思います。ルールがよく判らん。

2024/09/09

本日休業。役所手続きとか色々。

Turing Complete」 というCPUを作るゲームがあるというのを知ったり。ほぅ....

2024/09/08

AM中に起床。

掃除したり洗濯したり。

エアコンから大量の水が落ちてきて水浸し。ひとまず運転を止めたけど暑くて死亡。

2024/09/07

AM中に起床。

日が暮れた頃に散髪にお出かけ。

Emacsの雑記」を更新しました。 文章の微改版ついでに、以前対応したImageMagickのパッチ更新も 行なってみました。御参考まで。

2024/09/06

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

Web巡回して終了。

2024/09/05

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

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

2024/09/04

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

screen 5.0.0 のCygwinビルド。 コンパイルエラーやリンクエラーになる関数呼び出しを行なわないようにして取り合えず 起動だけできるようにしてみました。 hardstatusの色指定の互換性が無くなっている点については、 以前、gitのmasterを試した時に調べた通りに 移行すれば大丈夫そう。前試した時は気づいていなかったのですが、 色味が若干違っていたのを少し調整して以下のような感じになってみました。

screen 5.0.0 on Cygwinテスト

フルカラー表示になっているようです。ちゃんと対応されたものはCygwinパッケージで リリースされるのを期待しよう😅。

そういえば、最初に screen 4.x向けの .screenrcを読み込んだのですが、日付と時刻が表示されてるなぁ? と思ったり。以前 git masterを試した時は hardstatusに 日付(%Y/%m/%dなど)や時刻(%c)を表示する組み込みの方法が無くなって、 外部コマンドを実行しなくてはならない事になっていましたが、5.0.0では取り下げられているみたい。 なので、色指定をフルカラー指定に変更する以外はそのままで大丈夫そうでした。 外部コマンドでの対応も可能なので(今回のスナップショットはそれで対応したもの)、 日付や時刻以外のものを表示したい場合は外部コマンドで文字列を得て表示する事は可能と思います。

2024/09/03

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

GNU screenの 5.0.0がリリースされているらしいのを知ったり。 最寄りのftpサイトからソースアーカイブをダウンロードしてCygwinでビルドを試みたのですが、 PAM が見つからなくてエラー。 なんか以前見た記憶が。 PAMを外してみたのですが、コンパイルエラーでビルドできず。むーん。

そういえば、いつからか tarコマンドはアーカイブが圧縮されていれば自動的に判定&展開されるのを知りました。 習慣的に「xz -dc foo.tar.xz | tar xf - 」みたいに実行しているのですが、 かつて 「tar xf foo.tar.xz」を「tar cf foo.tar.xz」と間違えるとファイルが壊れる事が あったからという理由でした。今のtarコマンドだと「空のアーカイブ作成はご容赦願います」って エラーになって元のアーカイブファイルが壊れる事は無いみたいです。 ただし、バックアップから戻す目的で「tar xf foo.tar.xz file1 file2」みたいに 所望のファイルを上書き展開するつもりが 間違えて「tar cf foo.tar.xz file1 file2」って やってしまうとやっぱりダメなのですが😓。 オプションがイマイチどう解釈されるのか今だに慣れないのと、 ssh接続した リモートマシンとの間で データ転送するときの応用を忘れないようにする為に、 これまで通り 圧縮/展開プログラムと tar はパイプで繋ぐスタイルで行きたいと思います。

先日、Edgeで使用するフォントが変わっている話を記したのですが、 Chromeも 標準フォントに「Noto Sans CJK JP」を、固定幅フォントに「BIZ UDGothic」が使用される ようになっているようです。「Noto Sans CJK JP」は たまたま我が家のPCには インストールされていたのですが、入っていなければどうなるのだろうか? 因みに 現在はダウンロードできないっぽい?

2024/09/02

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

調べ事をして終了。

2024/09/01

昼頃起床。寝すぎ。

掃除したり。

Emacs30では アンダーラインのスタイルが追加されるらしい。

underline styleテスト

どうやって指定するのか判らなかったのですが、ELISPのinfoの Face Attributes によると 「:underline」にリストで追加のアトリビュートを指定する感じらしい。 「:style wave」は Emacs29とかでも使えていたようですが、Emacs30では double-line、dots、dashes が追加されるという事みたい。wave以外は text-scale-adjustにも適度に追従するみたいですが、 waveだけは追従しないっぽい。なので解像度によってはよく見ないと波線と判らないかも知れません。

たまたま underlineの近くに slantの説明があったのを何気にGoogle翻訳すると italicも obliqueも 「斜体」って翻訳されるなぁ?と思ったりも。 以前知った通り、厳密にはイタリック体と オブリーク体(斜体)とは違うものですが、Google翻訳では厳密に使い分けられてはいないようです。 この為、例えば 英語の「Italic type」の Wikipediaページを日本語に翻訳すると タイトルが「斜体」になるようです。 でも、翻訳された内容は「真のイタリック体」と「斜体」という風にちゃんと使い分けて 翻訳されているようです。ただし、文を選択してそこだけ翻訳するとやっぱり「Italic」が「斜体」と 訳される場合があって、翻訳結果に揺れが生じるみたい。


TOP

古いの
2024.08 2024.07 2024.06 2024.05 2024.04 2024.03 2024.02 2024.01
2023.12 2023.11 2023.10 2023.09 2023.08 2023.07 2023.06 2023.05 2023.04 2023.03 2023.02 2023.01
2022.12 2022.11 2022.10 2022.09 2022.08 2022.07 2022.06 2022.05 2022.04 2022.03 2022.02 2022.01
2021.12 2021.11 2021.10 2021.09 2021.08 2021.07 2021.06 2021.05 2021.04 2021.03 2021.02 2021.01
2020.12 2020.11 2020.10 2020.09 2020.08 2020.07 2020.06 2020.05 2020.04 2020.03 2020.02 2020.01
2019.12 2019.11 2019.10 2019.09 2019.08 2019.07 2019.06 2019.05 2019.04 2019.03 2019.02 2019.01
2018.12 2018.11 2018.10 2018.09 2018.08 2018.07 2018.06 2018.05 2018.04 2018.03 2018.02 2018.01
2017.12 2017.11 2017.10 2017.09 2017.08 2017.07 2017.06 2017.05 2017.04 2017.03 2017.02 2017.01
2016.12 2016.11 2016.10 2016.09 2016.08 2016.07 2016.06 2016.05 2016.04 2016.03 2016.02 2016.01
2015.12 2015.11 2015.10 2015.09 2015.08 2015.07 2015.06 2015.05 2015.04 2015.03 2015.02 2015.01
2014.12 2014.11 2014.10 2014.09 2014.08 2014.07 2014.06 2014.05 2014.04 2014.03 2014.02 2014.01
2013.12 2013.11 2013.10 2013.09 2013.08 2013.07 2013.06 2013.05 2013.04 2013.03 2013.02 2013.01
2012.12 2012.11 2012.10 2012.09 2012.08 2012.07 2012.06 2012.05 2012.04 2012.03 2012.02 2012.01
2011.12 2011.11 2011.10 2011.09 2011.08 2011.07 2011.06 2011.05 2011.04 2011.03 2011.02 2011.01
2010.12 2010.11 2010.10 2010.09 2010.08 2010.07 2010.06 2010.05 2010.04 2010.03 2010.02 2010.01
2009.12 2009.11 2009.10 2009.09 2009.08 2009.07 2009.06 2009.05 2009.04 2009.03 2009.02 2009.01
2008.12 2008.11 2008.10 2008.09 2008.08 2008.07 2008.06 2008.05 2008.04 2008.03 2008.02 2008.01
2007.12 2007.11 2007.10 2007.09 2007.08 2007.07 2007.06 2007.05 2007.04 2007.03 2007.02 2007.01
2006.12 2006.11 2006.10 2006.09 2006.08 2006.07 2006.06 2006.05 2006.04 2006.03 2006.02 2006.01
2005.12 2005.11 2005.10 2005.09 2005.08 2005.07 2005.06 2005.05 2005.04 2005.03 2005.02 2005.01
2004.12 2004.11 2004.10 2004.09 2004.08 2004.07 2004.06 2004.05 2004.04 2004.03 2004.02 2004.01
2003.12 2003.11 2003.10 2003.09 2003.08 2003.07 2003.06 2003.05 2003.04 2003.03 2003.02 2003.01
2002.12 2002.11 2002.10 2002.09 2002.08 2002.07 2002.06 2002.05 2002.04 2002.03 2002.02 2002.01
2001.12 2001.11 2001.10 2001.09 2001.08 2001.07 2001.06 2001.05 2001.04 2001.03 2001.02 2001.01
2000.12 2000.11 2000.10 2000.09 2000.08 2000.07 2000.06 2000.05 2000.04 2000.03