オタク日記
(Mac と Linux, 2018Q3)

---

2018-09-30 (Sun): 保守速報 (その 5)—GnuPG

Security に関しては、大昔から本質的なところはあまり変えていないが、 それで問題なく推移してきた (と信じている)。まあ、主に Linux (Ubuntu) と macOS なので、元々「脅威 (threats)」は少なく、あまり自慢にもならない。

ただ、2012 年頃、特に秘密を守りたいファイル (個人的な日記とか、 "key ring" とか) については、それらを rsync で複数のホストの間で共有している事もあり、特に保護したい、と思い立った。 つまり、何らかの方法で「ホスト内にログインを許してしまう」とか、「rsync の際に intercept される」等の場合でも、passphrase を知らない人にそれらのファイルを読まれないようにしたい、という事。

その前から、email を encrypt して……という試みはやっていたが、 結局立ち消えとなった。(数人の方々と public key を交換したような記憶があるものの、 今となっては、記憶の闇に……) その時に使っていた gnupg を流用した、 という事もあり、あまり熱心に記録を取ってないので、かなり時系列があいまいであるが……

• encrypt/decrypt には GnuPG (gpg) を使う事にする——macOS, Linux (Ubuntu, Raspbian) 等の host の間で共通に使えるので。実際、Linux (のどれか) で作った .gnupg の下の key を、他の Linux や macOS でも使う事ができた。(どうも、gnupg が持つ encryption の型の中で、 symmetric encryption というものを使い始めた、という事のようだ。)

  fukuda@falcon:~% gpg --list-keys
  /Users/fukuda/.gnupg/pubring.gpg
  --------------------------------
  pub   rsa2048 2012-06-28 [SC]
        79996C8AA7B208F600002167AA7D61CCE8C1F0A5
  uid           [ultimate] Taka Fukuda (Waremokau) <fukuda@computer.org>
  sub   rsa2048 2012-06-28 [E] 

• その内に emacs の EasyPG というものを知る。 これによれば、.gpg という suffix のついたファイルを読み込もうとすると、自動で decryption をやってくれ、 セーブの際には、また encryption をやってくれる。つまり、一々 encrypt/decrypt を CLI でやる必要が無い上に、 うっかり平文のファイルをどこかに残してしまう、というチョンボも防げる。 (実は、これをやってしまった。で、Time Machine によるバックアップがからむと、 (バックアップディスクを含む) 全ストレージの上から完全に消してしまうのは至難の技となる……。) さらに、平文の仮ファイルをディスクに置く事がないのは勿論、 メインメモリ上にも展開される事がないのだとか？ まあ、そこまで厳重にやってくれなくても良いのが、 とにかく便利で、これを採用してから、平和に安全に暮していた……
• EasyPG はその後、emacs (emacs-mac) の標準パッケージとなり、 パッケージ名も、epg に変わった…… (これはやり過ぎだわ、elpa さん。)
• 並行して GnuPG も進化を続け、この間、1.4x, 2.0.x, 2.1.x, 2.2.x と推移し、 根本のコンセプトが変わり (primary/sub-key なんてものが導入された) 、 外部ライブラリ (libgcrypt) を使うようになり、 gpg-agent と pinentry が必須となった。 実は、ちゃんとフォローアップしてきた訣ではなく、大昔に作った key と EasyPG の組み合わせが使えている限りは、無造作に MacPorts まかせで、gnupg (gnupg-2.1, gnupg-2.2) と Emacs (後には Emacs-mac) をアップグレードしてきた。
• 実は、或る日、gnupg-2.x がディフォルトになり、単に gnupg とすれば、 それは、gnupg2 (gnupg-2.x) を指し、gnupg-1.x を指定するには、gnupg1 としなければならない、とか、gnupg21 という新しいパッケージができる、 等のスッタモンダが有った (ような) のだが、それも何とか凌いできた。
• しかし、一度、gpg-agent がディフォルトとなったバージョン・アップ (もしくは、その次) で、「decryption ができない」というエラーが出るようになり大いに焦ったが、結局

  fukuda@falcon:~% killall -HUP gpg-agent

  とする事で、復旧できた。(実は、gpg-agent が必須となった事を知らなかった。)
• さらにその後、pinentry (と一緒にインストールする事) が必須となり、

  fukuda@falcon~% port installed gnupg2
  The following ports are currently installed:
    gnupg2 @2.2.10_0+pinentry_mac (active) 

  それに伴なって今回の異変？が起きた。
  • .gpg を emacs(-mac) で読み込む時、passphrase を聞かれなくなってしまった……passphrase を聞かれないまま、 ちゃんと復号されたテキストが読み込まれる。
  • かつてのトラブルのように、「復号できない」というよりはマシだが、 しかしこれでは、.gpg ファイルで保存する意味が全くない。
  • ということで、ちょっと真面目に調べてみた。(例によって) 途中の右往左往を端折ると、どうやら、EasyPG も pinentry も直接は関係なくて、 gpg (gnupg2) そのものが、passphrase の cache を全くコントロールできていないという事のようだ。

ちょっと考えればわかる事だが、これでは、(GnuPG 導入の) 本来の目的を全々達成できていない。例えば、まんまと ssh で侵入したハッカー、 もしくは、電車内に忘れた MBA の前に座ったハッカー他は、 .gpg ファイルを、他のファイルと同様、 何の苦労もなく読めてしまう……

明らかに、gnupg2 のバグだと思えるが、当面は対策を取らず、gnupg2 のパッケージが改善するのを待つ事にした。下手に弄ろうとして、 平文の Text ファイルが拡散してしまうのが怖い、というのもあるし、 これまで侵入された事がないので、もうちょっと gnupg2 が改善されるのを待っても大丈夫だろう……などという甘い考えもある。

---

2018-09-12 (Wed): 保守速報 (その 4)—EmacsMac

このところ「帰省」したり他所へ出向いたりする事が増えたせいで、MBA (MacBook Air) を整備する必要が出てきた。やってる途中で、 これまでの「保守速報」で書き漏らした事がいくつか見つかったので、 新たにやった事も含めて書き足しておく。

Wanderlust

EmacsMac.app を立ち上げた直後に Wanderlust を起動すると、

Symbol’s function definition is void: find-coding-system

と言われる。ただし、これは、かなり古い「問題」で、 一年程前から悩んでいる。Elisp はよく分からないのだが、 分らないなりに、いろいろ「追及」した結果

• 件の find-coding-system は、apel の pces-e20.el というファイルで定義されている

  (defsubst-maybe find-coding-system (obj)
    "Return OBJ if it is a coding-system."
    (if (coding-system-p obj)
        obj))

• この defsubst-maybeが曲者らしいが、 -maybeを取ったり、defun と変えても問題は解決しない。
• そもそも、pces-e20.el は、XEmacs のためのものらしいので、emacs-26 では読み込まれないのかも知れない。
• 結局 (従来通り) wl を起動する前に、ddskk (C-x C-j) か、lookup (C-x C-y) を起動する事で凌いでいる。

Lookup

これは、lookup の立ち上げ時ではなくて、 辞書の検索結果を表示する段階で、

Symbol’s function definition is void: insert-string

とやられる。これはどうも、Emacs-26 では、関数 insert-string が定義されていない、という事のようで、 init.el の先頭近くに

(defalias 'insert-string 'insert)

という行を挿入する事で解決される。

Major-mode ごとにフォントを変える

前にも (何度か) 述べたように、EmacsMac のフォントとして長らく Lucida FAX (改) + Hiragino Mincho ProN を使ってきた。 これはつまり全ての Major mode で、これを使ってきた、という事。

少し前に、Major mode ごとにフォントを変更できる事を知り、Programming-mode や Dired, Term などで、Luxi Mono を使う事を試みている。これは、init.el に

(defun my-buffer-face-mode-fixed ()
   "Sets a fixed width (monospace) font in current buffer"
   (interactive)
   ;;   (setq buffer-face-mode-face '(:family "Inconsolata" :height 140))
   (setq buffer-face-mode-face '(:family "Luxi Mono" :height 190))
   (buffer-face-mode))

(add-hook 'python-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'lisp-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'emacs-lisp-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'term-mode-hook 'my-buffer-face-mode-fixed)
(add-hook 'dired-mode-hook 'my-buffer-face-mode-fixed) 

と書く事で実現される。首尾は上々で、

Python, Lisp などのソースコードは見易くなった。

(クリックして拡大可) ただまあ、Lucida FAX (改) の「改」は、空白や記号の幅をやや大きくして、 コードを表示した時の違和感を減らすための「改造」なので、 この程度の規模では然程差は出ないかも。(Python で、インデントが深くなり、 かつ、if 文の条件式が複雑になった場合には有効。)

Dired, Term などでは効果大

しかし、Term mode や Dired などでは、歴然とした差が出る。

早速、Term mode を再び使い始めてみたが、見た目が大きく改善された事と、 「コマンド出力を他のバッファへコピーする」等の操作が大幅に改善されたが、 そうするためには、やはり Term の char-mode と line-mode の間を行ったり来たりせねばならず、これがかなり面倒な事、また、 zsh の動作が時々おかしくなる等の困難はやはり残っており、 程なく EmacsMac.app と Terminal.app の両方を使う従来のやり方に戻ってしまった。

---

2018-08-22 (Wed): 保守速報 (その 3)—Django

Django が 2.x になり、これまで書き溜めてきた App 達を、この際「Django-2 対応にしてから公開しよう」 なんて思ったのが間違いの始まり。 いや、そこまでは「間違い」というより「殊勝な心掛け」というべきか。 間違いは、"Class-base View" に興味を持った事かも。 これには往生している……

それでも、ずっと使っている DMS (Document Management System) <http://dms.waremo.com> はそんな悠長に構えているわけには行かないので、Django 2.x 対応のみを急いて、とりあえず動くようにした。目立った (必須の) 変更は、

• urls.py で、主に url(xxxx) を使っていたのが、path(xxxx) を使う事になった。
• csrf_token を明示的に template に渡す必要は無くなった。
• User Login を独自の views.py の関数でやるのではなく、 Django の admin でやる事にした。

途中、dict の「代入」が copy でない事を失念している箇所のせいで、 微妙な問題が露になってくる、なんて事も有ったが、とりあえず動くようにできて、 実稼働しているサイトに投入した。

その後は、Django や WSGI のアップデートの度に、(ちょっとだけ) ヒヤヒヤしながら、でも結局は何事もなく、 MacPorts のアップデートをやってきた。

今回、Django が 2.0.7 から 2.1 になる際も、1.11.x から 2.0 になるより時よりはインパクトは少ないだろうと高を括って、 いきなり公開サーバで Django をアップグレードする等という無謀な事をやったら、 見事に Error 500 (Internal Server Error) が出た T_T;

少々焦ったが、こういう時に PyVenv は便利で、requirements.in の中で、

.....
django==2.0.7
.....

として、pip-compile/pip-sync するだけで元に戻せた。

これで、ちょっと余裕が出たので、Log を調べてみると、 views.py の中で、

from django.contrib.auth.views import password_change 

が Import Error になっている。 何でこんな事になったか、ちょっと顧みると……

1. Django-1.11 で、django.contrib.auth.views の change_password() を含む多くの関数が deprecate になっている。
2. が、無視して使ってきた。
3. -2.0 になる時に、さすがにヤバそう、という事で、 これを使わない方向でコードを改訂。 が、この import 文だけ、消去するのを忘れていた。
4. 2.0 ではなく、2.1 になって、deprecate から、 removed (「使用不可」) となって、Error: 500 に！

という事らしい。なんで、2.0 でなくて 2.1 で「誤り」にしちゃうかなぁ…… というボヤキは飲み込んで、falcon 側で views.py のこの行を消去して

fukuda@falcon:~/wrm_dms2% git commit -a -m "removing deprecated func, change_password()"
fukuda@falcon:~/wrm_dms2% git push origin master --tag

digoc02 側で、required.in で、django==2.0.7 のバージョンの縛りを取り払い、

fukuda@digoc02:~/wrm_dms2% git pull origin master --tag
fukuda@digoc02:~/wrm_dms2% sudo service apache2 reload

とする事で、通常の「運転」に戻す事ができた。

---

2018-08-15 (Wed): 保守速報 (その 2)—EmacsMac

例によってあまり注意を払わず MacPorts の EmacsMac.app をアップグレードしたら、いきなり 7.1 となった。基になった Emacs のバージョンは 26.1。

fukuda@falcon:~% port installed emacs-mac-app
The following ports are currently installed:
  emacs-mac-app @7.1_0 (active) 

少し前までなら、「わーい、ワクワク、ドキドキ」だったろうけど、 今はさすがに「大丈夫かなぁ」と心配に…… (トシのせいか :-))

が、しかし、「案ずるより……」で、emacs-mac-app-6.8 ? まで使ってきた ~/.emacs.d/{init.el,.emacs-custom.el} のままで、 -7.1_0 がとりあえず 立ち上がった。あとは、package.el がうまく動いてくれれば、 あまり互換性の心配はしなくて良い筈……

Package (package.el)

果して、package.el は M-x package-list-packages で立ち上がってくれた。 例によってアップグレード可能なパッケージをしばらく捜した後、 'U' ('Upgrade') をキーインすると、「全部アップグレードするべし」と。 (つまり、installed package の頭に 'D' がつけられた……) 言いなり、で 'X' ('eXecute'?) をキーインすると、しばらくかかった後、 殆んど問題無く全部のパッケージがアップデートされた模様。

ただ、package.el 自体も相当変わったようで、

• アップグレード前の旧バージョンを残すかどうか聞いて来なくなった (これは大分前からそうだった？)
• 従来の 'available', 'installed', 'built-in' の 'Status' に加えて、 'dependency', 'incompat' (incompatible?) 等が加わった。

これらによって、結局以下のような表示が得られる。

どうやら、'dependency' は、依存性解決のために package.el が自動で入れた package, 'incompat' は、新 Emacs に対しては、 互換性の有るバージョンが得られなかった package, という事らしい。

Lookup/EBlook

辞書を引くためも「コマンド」 'eb', 'eblook' は MacPorts に入っている。 が、開発が止まってしまったのか、インストールして随分経つが、 まだ、アップグレードされる気配は無さそうだ。

fukuda@falcon:~% port list | grep eblook
eblook                         @1.6.1-media-20150724 textproc/eblook
fukuda@falcon:~% port list | grep -e '^eb '
eb                             @4.4.3-20130920 textproc/eb
fukuda@falcon:~% port installed eb eblook
The following ports are currently installed:
  eb @4.4.3-20130920_0 (active)
fukuda@falcon:~% which eblook
/opt/local/bin/eblook

うーむ、eblook は有るのに、port は認識していない……。 ここはちゃんとしておきたい。

fukuda@falcon:~% sudo port install eblook
.....
--->  Installing eblook @1.6.1-media-20150724_1
--->  Activating eblook @1.6.1-media-20150724_1
Error: Failed to activate eblook: Image error: /opt/local/bin/eblook already exists and does not belong to a registered port.
.....
fukuda@falcon:~% sudo port -f activate eblook
fukuda@falcon:~% port installed eblook eblook
The following ports are currently installed:
  eb @4.4.3-20130920_0 (active)
  eblook @1.6.1-media-20150724_1 (active)

肝心の lookup (eblook への emacs API) は、emacs package に入っていず、 手で入れていた (lookup-1.4+media-20170115)。 それでも、Emacs が 26.1 になっても、問題無く動いた (Kazuhiro Ito さん、凄い！感謝！)。 が、2018年版が出ていたので、この際アップグレードする事にした。

いつもの Kazuhiro Ito さん のところから、 lookup-1.4+media-20180325.tar.gz をダウンロード

これを展開して configure/compile/install する。

fukuda@falcon:~/build/lookup-1.4+media-20180325% ./configure \
   --with-lispdir=/Applications/MacPorts/EmacsMac.app/Contents/Resources/site-lisp \
   --infodir=/Applications/MacPorts/EmacsMac.app/Contents/Resources/info
fukuda@falcon:~/build/lookup-1.4+media-20180325% make
fukuda@falcon:~/build/lookup-1.4+media-20180325% sudo make install	  

'defer' を OALD で引いてみた。ちゃんと動いているようだ。

Wanderlust/W3m

Wanderlust (以下 'WL') はこれまでも色々問題が有って、「Mac でハック」がいつまでも完成しないのはこのせいだぁ、 などと言ってきたけど、実はこの半年程はとても安定している。 実際、EmacsMac を 7.1 に上げた時点では、他の App と同様問題無く動いていた。 但し、

• Emacs を立ち上げた後、即 'WL' を起動すると、 "Symbol’s function definition is void: find-coding-system" というエラーになる。(DDSKK を起動しておくと問題無い。)
• AT&T 系の ISP のアカウントにメールが届かない。 (これは多分 Wanderlust のせいではないだろう。)

等の問題は従来通り。

その後、apel, flim, semi, w3m, wanderlust 等の package が upgradable になる度に「言いなり」でアップグレードしていたが、 ある日突然、'WL' が立ち上がらなくなった……。debug-on-error で、messaeg を取ったが、あまり参考にならない。

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  signal(wrong-type-argument (stringp nil))
  wl(nil)
  funcall-interactively(wl nil)
  call-interactively(wl record nil)
  command-execute(wl record)
  execute-extended-command(nil "wl" "wl")
  funcall-interactively(execute-extended-command nil "wl" "wl")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command) 

幸いにも、もう一つの High Sierra マシンでは、これらの package のアップグレードをサボっているので、まだ問題なく動いている。 なので、それらの古いパッケージと置き換えるなど、色々四苦八苦してみたが、 原因は不明のまま。ふと思いついて、.folders から、Shimbun Folder (下のリスト参照) を外してみたら、これが大正解。

News{
# 	@asahi.editorial
# 	@asahi.tenjin
#	@asahi/
  	@bbc.news
}

朝日新聞の記事は疾に読めなくなっていたので、新たに諦めるのは bbc.news だけだが、これはちょっと辛かったな。

ともあれ、これで一安心、と思ったがちょっと甘かった……。 'WL' は立ち上がり、Folder も開けるのに、その中の message に開けないものがある……。しかも沢山。よく見たら、HTML ソースを含むメールが開けないという事のようだ。

当然 (emacs-)w3m を疑うべきだが ('WL' は、HTML の部分を emacs-w3m を使って表示している) 、今まで問題になった事が無かったので、 なかなか思い至らなかった。 が、まさか、と思いながら 'M-x w3m' とやったら、エラーになった。debug-on-error で取れたメッセージは、

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("/" nil 0)
  split-string(nil "/")
  mailcap-mime-info("desc=\"ltspice")
  (setq viewer (mailcap-mime-info type)) .....
  (if (= 0 (length ext)) nil (setq exts (list ext)) ....
  (while (setq elem (car-safe (prog1 extensions ....
  (let ((additions '(("text/sgml" "\\.sgml?\\'" nil "text/plain") ....
  (defvar w3m-content-type-alist (let ((additions '(("text/sgml" "\\.sgml?\\'" ....
  eval-buffer(#<buffer  *load*> nil "/Users/fukuda/.emacs.d/elpa/w3m-20180404.2220/w3m.el" nil t)  ; Reading at buffer position 48001
	  load-with-code-conversion("/Users/fukuda/.emacs.d/elpa/w3m-20180404.2220/w3m.el" "/Users/fukuda/.emacs.d/elpa/w3m-20180404.2220/w3m.el" nil t)
	  autoload-do-load((autoload "w3m" "Visit World Wide Web pages using the external w3m command.\n\n".....
	  command-execute(w3m record)
	  execute-extended-command(nil "w3m" "w3m")
	  funcall-interactively(execute-extended-command nil "w3m" "w3m")
	  call-interactively(execute-extended-command nil nil)
	  command-execute(execute-extended-command)

うーむ、mailcap-mime-info() の引数 (type?) に、なんで ltspice 云々が入るのか分らん……ていうか、そもそも自分には「elisp は謎」なので、w3m package が新しくなるのを待つしかない？

といいつつ、ちょこちょこ触っていたが、package.el でインストールした w3m をどうしても動くようにできないので、 仕方なく、個別にインストールした emacs-w3m を使う事にした。まず、package.el で w3m を 'D' (delete) して、 隠していた既存の (emacs-)w3m を site-lisp に戻す……

fukuda@falcon:/Applications/MacPorts/EmacsMac.app/Contents/Resources% \
    sudo mv hide/w3m site-lisp/
fukuda@falcon:/Applications/MacPorts/EmacsMac.app/Contents/Resources% \
    ls -l site-lisp/w3m
total 5124
-rw-r--r-- 1 root wheel 404758 Jan 27  2015 ChangeLog
-rw-r--r-- 1 root wheel 246138 Jan 27  2015 ChangeLog.1
-rw-r--r-- 1 root wheel   3318 Jan 27  2015 bookmark-w3m.el
-rw-r--r-- 1 root wheel   1285 Jan 27  2015 bookmark-w3m.elc
-rw-r--r-- 1 root wheel  36825 Jan 27  2015 mew-shimbun.el
	....

なんと、2015 年のだったか……

load-path を更新するために、EmacsMac を再起動 (もっとスマートなやり方が有ったように思うが)。 すると、emacs-w3m が立ち上がった。

気をよくして、Wanderlust を立ち上げて、html part を持つメールを開いてみたが、問題なく読める……。 さらに、上で駄目だと思って消してしまった、shimbun folder (@bbc.news) さえ読めるようになった…… うーむ、全ての問題は、w3m の、パッケージ・ミスが原因だったかぁ。

w3m            20180405.520  available  melpa      an Emacs interface to w3m
w3m            20180404.2220  available  melpa      an Emacs interface to w3m

上が最新版、下が MBA でたまたま残っていて、問題無く動くもの。 たった一日違いで……しかも、その後 4 ヶ月も放置か。悲しいねぇ。

が、偶々別件で自分の日記 を見返していると、wl で w3m の代りに eww を使う、という記述を見付けた。 (厳密には、semi が MIME-View でどちらかを使う、という意味。) 加えて、semi(-epg) が、「w3m が無ければ eww を使う」という事も。 で、

1. せっかく元に戻した (古い) w3m だけど、また site-lisp/../hide/ に戻して、
2. .folders で、shimbun folder ('@' で始まる) を消して、
3. init.el で w3m を load しているところを全部コメントアウトして、

emacs をリスタート。なんと、これだけで、殆んど全ての HTML part を持つメールを開けるようになった。

正直に言うと、「'WL' は、衰亡の一途か？」なんて思い始めていて、 「Mail.app だけで何とか凌ぐ方法」を模索し始めていたけど、 w3m (とその shimbun) を捨てる事で、まだまだ 'WL' でやれる！ という気がしてきた——なんだかまた元気が出てきたぞ。

---

2018-08-08 (Wed): 保守速報 (その 1)

(ちなみに、ネトウヨ様御用達の「保守速報」とは関係ありません。 こっちは、保守 = maintenance です。:-p)

このところ、Otaku_comm の更新が滞っている。 実は、面目を一新しよう等と大それた事を目論だのは良かったのだが、 案の定大幅に予定が遅れている…… なので、ごちゃごちゃやってる事を態々ウェブに上げる事もないか、と思った訣。 でも、半年もサボると (つまり、やった事を曲がり形にもこのページ程度には整理しておかないと)、 後でわけわかになる、って事を痛感しはじめたのでした。

AquaSKK

つい最近まで、どこかから最新の dmg ファイルを見付けてきて、 それをインストールする、で何とかなっていたんだけど、 どこか不安だった。「ここだけ見ていればいい」というサイトが無いように思えたし、 MacPorts の一部になる動きもないようだし……

-4.4.5 へは、macOS を High Sierra に上げた時に、アップグレードしたのだった。 (「ついで」だったか、半強制的に上げざるを得なかったか、憶えていない。) それはもう 5ヶ月も前の話なので、もうそろそろ上がっているのではないかな、 とちょっと捜してみたけど、それらしいパッケージは見付からない。

-4.5.0 へのアップグレード

でも、github では、遠の昔に -4.5.0 にアップグレードされている…… という事で、無謀かな、と思いつつ、github のソースから make/install してみる事にした。

実は、ちょっと前から同 github は使っていて、リポジトリはできている (コンパイルがうまく行かなかった) …… 多分以下のようにやったのだろう

fukuda@falcon:~/Git% git clone https://github.com/codefirst/aquaskk.git

それから日も経っているので、git pull から始める……

fukuda@falcon:~/Git/aquaskk% git pull origin master
fukuda@falcon:~/Git/aquaskk% cd platform/mac
fukuda@falcon:~/Git/aquaskk/platform/mac% ls
Makefile  pkg/  plist/  proj/  src/
fukuda@falcon:~/Git/aquaskk/platform/mac% make install-rc

コンパイルにもリンクにも結構時間がかかるし、ワーニングも出まくりだけど、 なんと、これだけでインストールまで完了してしまった！ ('install-rc' は、dmg ファイルをビルドして、 それをインストールする、というターゲットらしい。)

へぇーっ、とつかのま感心したけど、考えてみれば、変更してある config file をディフォルトのファイルで上書きしてしまった、 という事でもある。何度目かの失敗で「またやっちまった」と少々がっかりしたけど、 気を取り直して、Time Machine から kana-rule.conf と keymap.conf を掘り出して、 /Library/Input Methods/AquaSKK.app/Contents/Resource/ の下に置く事で、元に戻せた。(次節で、このあたりの対策について触れる。)

辞書と設定ファイル

アップグレードの度に思い出さないといけない事項のまとめ:

• /Library/Input Methods/AquaSKK.app/Contents/Resource: ディフォルトの設定ファイルの置き場所。AquaSKK のインストールの度に上書きされる。
  • keymap.conf:
  • kana-rule.conf:
  • old-kana.rule:
  • BlacklistApps.plist:
  • DictionarySet.plist:
  • ...
• ~/Library/Application Support/AquaSKK/: 個人用設定ファイルと辞書はここに置かれる。(AquaSKK のインストールの際に上書きされない。)
  • skk-jisyo.utf8 #1)
  • BlacklistApps.plist: #2)
  • DictionarySet.plist: #3)
  • SKK-JISYO.L #4)
  • SKK-JISYO.JIS3_4 #4)
  • ...
  • keymap.conf: #5)
  • kana-rule.conf: #5)
  ここに、
  1. #1) AquaSKK の個人辞書。変換を行なうとその結果がキャッシュされる。 (最も頻繁に更新される。)
  2. #2) AquaSKK が随時アップデートしている模様。
  3. #3) AquaSKK の 「環境設定」→「辞書」 で変更すると、結果がここに反映される。
  4. #4) 上記で「有効」にすると、その辞書は AquaSKK によって、自動アップデートされる。
  5. #5) これらの設定は手で変更するしかなく、AquaSKK による更新はない。(自動では作製されない。)

現在の「設定」

AquaSKK は随分と長く使わせて頂いているが、途中 「AquaSKK 日本語を快適に」 のページがアップデートされなくなったという事もあり、 設定についてはかなり「わけわか」になっていた。で、この際、 ちょっと整理しておこう、と。

とは言え、もう自分が正字正假名を使わなくなった事もあり、 既に相当単純になっていた。 (何度かうっかりディフォルトで上書きしてしまった後、 元に戻すのをサボった、という事。)

• kana-rule.conf: (上記 #5) 参照) これは、
  • wi → ゐ, we → ゑ
  • '!', '?', '(', ')' を常に「全角」文字に
  のみが残っている。他の「環境設定」→「拡張設定」 の似たような「設定」は全部「無効」にした。結果、

  fukuda@falcon:~% diff Library/Application\ Support/AquaSKK/kana-rule.conf  
      Git/aquaskk/platform/mac/...../Resources/kana-rule.conf | lv -Ie
  217c217
  < wi,ゐ,ヰ,ｳｨ
  ---
  > wi,うぃ,ウィ,ｳｨ
  219c219
  < we,ゑ,ヱ,ｳｪ
  ---
  > we,うぇ,ウェ,ｳｪ
  278,281d277
  < (,（,（,(
  < ),）,）,)
  < !,！,！,!
  < ?,？,？,?

• keymap.conf: (上記 #5) 参照) これについても、(Terminal.app 等のように) Ctrl-J が横取りされてしまう App の上で「ひらがなモード」に入れるのに、Ctrl-; (semicolon) を使う、という変更だけを残した。つまり、

  fukuda@falcon:~% diff Library/Application\ Support/AquaSKK/keymap.conf \
      Git/aquaskk/platform/mac/...../Resources/keymap.conf | lv -Ie
  9c9
  < SKK_JMODE             ctrl::;||ctrl::j
  ---
  > SKK_JMODE             ctrl::j

• #5) で示唆したように、上記の二つのファイルを ~/Library/Application Support/AquaSKK/ に置く事で、「個人用設定」が AquaSKK の Install/Update に影響されなくなる。

結論

という程の事でもないが、今後は、github で upgrade があれば、 それを pull して build/install するだけで、OK となる (筈)。一歩前進。

Fonts

私にとっての macOS の最大のメリットは、フォントが美しい事。Mac に出戻ってからこちら (もう、10 年以上？) 'Luxi Mono', 'Lucida Fax (改)', 'Hiragino Mincho {Pro|ProN}' でやってきた。

Hiragino Sans

逆に言うと、これらのフォントはそれくらい古い、という事なのだが、 その間、これらを凌ぐものが出て来なかった、という事でもある。が、 High Sierra になって、若干事態が動いた。'Hiragino Kaku Gothic ProN' の構成が変わって、W0 から W9 まで完備するようになり、名前も 'Hiragino Sans' と変わった。 これがまたとっても具合が良い——特に W1, W2 のあたりが。

Firefox Fonts

早速これを使ったディフォルト・フォントの設定にしてみた。 例えば、Firefox では

残念ながら、上記設定画面では、Hiragino Sans の W (weight) を選べないのだが、見たところ W3 がディフォルトの模様 (従来通り)。

Terminal.app

Terminal.app は今 -2.8.2 であるが、Preference -> Profiles -> Font (Change) -> Fonts の画面で、collection として、all を選べば、Hiragino Sans を選ぶ事はできるが、 そうやっても、従来と同様、フォント間隔が大きくなりすぎて使い物にならない。

なので、collection として、'Fixed' か 'English' を選び、そこで Luxi Mono を選ぶしか選択肢は無い。この場合、2 byte code には Hiragino Kaku Gothic ProN W3 が従来通り選ばれている模様。(早い話が、Hiragino Sans は何の影響も与えていない。)

HTML

今のところ、Hiragino Sans の weight を明示的に選ぶのは、HTML の CSS でのみ可能なようだ。とりあえず

body {
    font-family: "Hiragino Kaku Gothic ProN"; 
    font-size: 18px; 
    line-height: 150%  
}

と

body {
    font-family: "Hiragino Sans"; 
    font-weight: 300; 
    font-size: 18px; 
    line-height: 150%  
} 

が、Firefox と Chrome の上でそれぞれ略同じになる事が確認できた。 (Firefox で設定やってみての「予想」が正しかった。) その上で、 font-weight を 100 や 200 にしてみたが、これはすっかり期待外れ—— 'font-weight: 300' の方がずっと見易い。

かつて、Kaku Gothic ProN W3 を「地の文」に適用したのでは「暑苦しいなぁ」と思ったが、 今ではこれが最適に思える。フォントの側が変わったのか、私の趣味 (もしくは視力) が変わったのか……。 ('Font Book' で、W2 の方が美しく見えたのは、フォントサイズが大きかったせいかも知れない。)

という事で、この方面においても、「大勢に影響なし」という事になってしまった。

---

244/1,788,174

Taka Fukuda

Last modified: 2018-10-04 (Thu) 15:49:42 JST