Orz日記 by Akio Morita

_ [FreeBSD]ee(1) on ja_JP.UTF-8

日本語(おそらくマルチバイト文字)を含む行末へCtrl-Eでカーソルを飛ばすと、 実際の行末より後ろにカーソルが飛んでいく

カーソルの位置計算がおかしい？

多分、eucJPだとワイド文字～2byte符号だったのが、utf-8だと典型的には3byte符号化している為では…

試しに、utf-8で一文字毎に送っていくと、ワイド文字で2回足踏みする

まあ、元々マルチバイト文字にきちんと対応していない訳なのだが、 eucJPだとそこそこ実用になったので重宝していた(軽いし)

_ [FreeBSD]kterm on ja_JP.UTF-8

LANG=ja_JP.UTF-8なKanjiMode utf8運用時、表示やコピーペーストは問題ないが、XIM入力が文字化けする

X Resource Databaseの状態が錯綜していたので、整理してみた...

• 標準状態でInput() @ input.cは、XIMのエンコードをja_JP.eucJPで初期化し、入力列にEUC-JPを期待しているが、convEUCtoUTF8によるEUC-JP→UTF-8で化ける (convUTF8へ渡ってくるUCS-4 BMPのコードポイントが既にあってない)
• eucJPLocaleリソースでXIMのエンコードをja_JP.UTF-8へ変更しても、input.c側はXIMからの入力をEUCとして処理するので、化ける

解決方法に関して、

1. convEUCtoUTF8をまともに修正する
2. eucJPLocaleをja_JP.UTF-8に設定し、Input() @ input.cでの変換を停止する

• (1)が使う変換テーブルは、convCStoUTF8で使うものと共通の模様 (convCStoEUCと読み比べればなにか分かるはず)
  • ucode_kanji1の参照位置が、convCStoUTF8の(c1-33)*94+(c2-33)に対し、convEUCtoUTF8は(c1-33)*94+(e2-33)で、e2=c2+0x80だから128-offsetして参照してる Orz
  • 治した

--- convert.c.orig      2016-11-05 06:41:21.000000000 +0900
+++ convert.c   2024-06-13 12:50:40.353827000 +0900
@@ -1106,7 +1106,7 @@
                        if (e2 = *es++) {
                                int c1 = e1 & ~0x80;
                                int c2 = e2 & ~0x80;
-                               int ucode = ucode_kanji1[(c1-33)*94 + (e2-33)];
+                               int ucode = ucode_kanji1[(c1-33)*94 + (c2-33)];
                                int len = utf8_len(ucode);

                                if (ucode == U_error) {

• (2)で、UTF-8モードが動くことは確認したが、EUC/SJIS/JIS Modeが使えなくなる(正確にはXIM経由が文字化けする)

素直にutf-8モードのxtermに移れ説はあるのだが、仕様しているフォントのグリフセットの都合で一部不具合が出るのでもうしばらくktermで頑張りたい (local filesystem上で、xterm向けのiso10646 fontにグリフが未実装な文字が使われてる)

_ [雑記]Let'snote FV5の意外な弱点

実は、LV8より単純にバッテリー容量が小さい

出っ張りの無いフラットデザインなため、単純に体積が減っているためと思われる (光学ドライブを下ろして空いたスペースにバッテリを配置し、キーボード下に配したメインボードを後方排気クーラーと直結するレイアウトなので、他に合理的な配置が無い＆前方配置なのでバッテリー部を厚くする余地が無い)

バッテリーパック(L)の仕様は以下の通り

バッテリ重量からみるとかなり健闘しているし、フットプリントが小さいSR/QR系よりマシなのだが…

バッテリパック(L)装着時のカタログ上の駆動時間は以下の通り

で、FreeBSD等で稼働状態でacpiconf -i0の推定稼働時間を測定してみると、LV8 5～6時間に対してFV5 4～5時間になる

acpiconfが報告するアイドリング時の消費電力は、LV8 8～9Wに対してFV5 9～14Wなので、 バッテリ容量の減少も相まって実稼働時間はかなり不利な模様

もちろん、稼働コア数(4C/8T vs 6P+8E+2LE/22T)を考慮すれば、大変効率的になっているのだが…

カタログ稼働時間は、電力消費をギリギリまで絞り込んだ値なんだけど、JEITA3.0もかなり現実から遠い気がする

現状、acpi_videoでバックライト制御が出来てない分は分かるが、CPUパワーとかどうやってそこまで絞ってるんだか Orz