オタク日記
(Mac と Linux, 2018Q3)
目次
2018-09-30 (Sun): 保守速報 (その 5)—GnuPG2018-09-12 (Wed): 保守速報 (その 4)—EmacsMac
2018-08-22 (Wed): 保守速報 (その 3)—Django
2018-08-15 (Wed): 保守速報 (その 2)—EmacsMac
2018-08-08 (Wed): 保守速報 (その 1)
古い日記:
2018Q2
2018Q1
2017Q4
2017Q3
2017Q2
2017Q1
2016Q4
2016Q3
2016Q2
2016Q1
2015Q4
2015Q3
2015Q2
2015Q1
2014Q4
2014Q3
2014Q2
2014Q1
2013Q4
2013Q3
2013Q2
2013Q1
2012 年
2011 年
2010 年
2009 年
2008 年
2007 年
2006 年
2005 年
2004 年
2003 年
2002 年
2001 年
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 になっている。 何でこんな事になったか、ちょっと顧みると……
- Django-1.11 で、
django.contrib.auth.views
のchange_password()
を含む多くの関数が deprecate になっている。 - が、無視して使ってきた。
- -2.0 になる時に、さすがにヤバそう、という事で、 これを使わない方向でコードを改訂。 が、この import 文だけ、消去するのを忘れていた。
- 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 を使う」という事も。 で、
- せっかく元に戻した (古い) w3m だけど、また
site-lisp/../hide/
に戻して、 -
.folders
で、shimbun folder ('@' で始まる) を消して、 -
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) AquaSKK の個人辞書。変換を行なうとその結果がキャッシュされる。 (最も頻繁に更新される。)
- #2) AquaSKK が随時アップデートしている模様。
- #3) AquaSKK の 「環境設定」→「辞書」 で変更すると、結果がここに反映される。
- #4) 上記で「有効」にすると、その辞書は AquaSKK によって、自動アップデートされる。
- #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 の方が美しく見えたのは、フォントサイズが大きかったせいかも知れない。)
という事で、この方面においても、「大勢に影響なし」という事になってしまった。
231/1,780,897 Taka Fukuda Last modified: 2018-10-04 (Thu) 15:49:42 JST