平衡点
2007/12/18
_ okumura-clsfiles 使用時の xdvi
TeX でjsarticleとかjsbookとかを使った際に xdvi での表示が kochi なのは悲しいので, 設定を調べると.
/etc/texmf/vfontmap.d/20ptex-jisfonts.map で直接 kochi が呼ばれていた. defoma でもってフォントを設定してあるので,
### For ptex-jisfonts @Mincho Roman|Mincho@ rml-jis JIS-H @Gothic SansSerif|Gothic@ gbm-jis JIS-H
に修正して,
$ sudo update-vfontmap
で ok. TeX 環境も更新.
_ CUPS で知らないプリンタが見えてた.
印刷する時に cupsys を起動して, 使わない時は落していたのですが, 今日起動したら「redhat-config-printer」 とか言う子が見えてた. うーん?
...某氏の計算機の共有プリンタっぽい. あれ, なんでこれが見えてるの?
CUPS はデフォルトで, 共有プリンタを検索して表示してくれている, という事だった. CUPS の設定で「管理」->「他のシステムで共有されているプリンタを表示」のチェックを外したら, 出なくなったよ.
...設定したプリンタを共有公開してるのは, なんか理由があるのかな. それとも, 私も公開しっぱなしだった? もしかして...
2012/12/18
_ mikutterのライセンスとか.
はじめに
この記事は mikutterアドベントカレンダー の 12/18 日分の記事です. ネタ以外のなんでもありません. 昨日は @iorivur の mikutterアドベントカレンダー17日め でした.
まあ, 昨日のうちにサーバに上げてはいたんだが, 公開設定忘れていたよ, みたいな. 順調に「ておくれ」ています.
普段 twitter は atig.rb : Another Twitter Irc Gateway と WeeChat, the extensible chat client から閲覧/更新しているので, mikutter は ネタとしてしか 使っていません. まあ, twitter のガイドラインも変更になった事ですし, そのうちコマンドラインから使えるようにゴニョゴニョして使うように なるかもしれません(し, しないかもしれません).
以前から手元で使うために mikutter の svn head を Debian パッケージにして使っていました. 最近Debian Developerである @dai_lxr さんが, mikutterを, Debianの公式パッケージにしようと, 作業して, いらっしゃるわけですが.
こういうソフトウェアをディストリビュータとして配布できる形にするのは とっても大変ですよね, みたいな気持です. それはそれとして.
ライセンス?
本家で「GPL3で浄化されています」とあります.
- vendor 以下には別ライセンスのソフトウェアが幾つかあります. 見てませんが, これらが矛盾していないなら, 全体として GPL-3?
- core/skin/data/icon.png は, アイコンでしょうか? 初音ミクさんおよびその派生物は CC BY-NC と PCL(ピアプロ・キャラクターライセンス) の デュアルライセンスですね.
- core/skin/data/twitter-bird.png は twitter のロゴですね. 詳細は Twitter / ロゴとブランド にあります.
…ええっと...浄化, されてるのかな...?
「カタイこと言うなや」って?
そういう問題ではありません.
なんでこんな事をわざわざ書いたん?
初音ミクさんが CC BY-NC と PCL(ピアプロ・キャラクターライセンス) のデュアルライセンスになったと聞いて.
実のところ, 「大丈夫なん?」と何度か会話しているわけですが. こうして指摘しておくとナイスガイ @toshi_a によって 綺麗に浄化されるに違いないと思います.
まとめ
以上, まとまってませんが. 皆さん楽しい mikutter life を.
明日 12/19 はたくみんさん(@uho_www)の予定です.
2014/12/18
_ NetworkManager で仮想環境用に bridge を作成
始めに
ラップトップでは上流のネットワークが有線だったり無線だったりで、ちょっと面倒ですね.
virt-managerなんかでdnsmasqを用いたNATネットワークを使うと,この辺上手くやってくれるので大分楽なんですけれど,
- そもそも,ホスト環境であるラップトップ側で dnsmasq は既に動いているので,virt-manager から dnsmasq が二重に上がる.別に何か問題がある訳じゃないけれど,気にいらない.
- 仮想環境側のアドレスがコロコロと変わるのがちょっと.dnsmasq の dhcpd 機能で IP を渡しているのだけれども,仮想MACアドレスに対応して固定のIPを振ったとしても,lease time が過ぎると毎回アドレス取得している感じ.
といった点が気になっていました.
そんな訳で,矢吹さんのノートPCで、LXCを運用するときのTIPS - Yukiharu YABUKI の tDiary(2011-10-30)を参考に bridge インターフェースを作成して iptables で NAT する様にしてみたのですが,今度は仮想環境側を落とした後に NetworkManager が
(プロセス番号) libnm-glib-WARNING **: Error in get_property: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
と悲鳴を上げる様になりました.
さて,どうするか,…としばし悩みましたが,良く見たら NetworkManager でも bridge を管理できるみたいで.試しに NetworkManager 側で bridge を作成してみたら上記の悲鳴は出なくなりました.というわけで,その手順のメモなど.
環境は
% lsb_release -a LSB Version: (略) Distributor ID: Debian Description: Debian GNU/Linux 8.0 (jessie) Release: 8.0 Codename: jessie
となっています(…が,sid です.良く見たら /etc/debian_version も 8.0 になってるな.freeze 期間だからかしら).Wheezy の NetworkManager でもブリッジって作成できるのかしらん?
NAT の設定
iptables で,bridge から現在接続されている上流(eth0 or wlan0) への NAT を設定します.
先ず /etc/sysctl.d/ 以下に適当なファイル名(vm-forward.conf としました)で以下の内容を記載しておきます.
net.ipv4.ip_forward=1
その後
% sudo sysctl -p
で設定を反映.
次に,iptables で
% sudo iptables -A FORWARD -i [bridge name] -s XXX.XXX.XXX.0/24 -m conntrack --ctstate NEW -j ACCEPT % sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT % sudo iptables -t nat -A POSTROUTING -s XXX.XXX.XXX.0/24 -j MASQUERADE % sudo iptables-save % sudo /etc/init.d/netfilter-persistent
として,iptables の設定を更新します. XXX.XXX.XXX.0/24 はブリッジに振る/仮想マシンに振る IP 空間, [bridge name] は作成する bridge インターフェースの名前です.
以上で,ブリッジインターフェースからの接続を上流に IP Masquerade できるようになります.
NetworkManager でブリッジの作成
nm-connection-editor で作成するのが楽です.自動起動にチェックを入れておくと,常にブリッジインターフェースが存在するので,ホストがネットワークに接続されていない場合でも仮想環境とは通信が可能です.
ちなみに,ログ見てたら /usr/bin/arping を実行しようとしていました. とりあえず /usr/sbin/arping からの symbolic link を貼っておきましたが, これ Bug なのかしら…?
virt-manager, lxc での設定
virt-manager で作成した仮想ネットワークは削除して,仮想マシン側で NIC に作成したブリッジを割り当てておきます.
lxc でコンテナを作成する際には
lxc.network.type=veth lxc.network.link=[bridge name] lxc.network.flags=up
としておけば良いかと.
まとめ
というわけで,気になっていた
- dnsmasq の二重起動
- 仮想環境側の IP を固定
- NetworkManager の悲鳴
が解決された様です.
外界と仮想環境とを接続したい,と思ったら一手間かける必要がありそうですが,とりあえずこれで運用して,どうなるか試してみます.
2020/12/18
_ emacs -nw
でこの先生きのこるには。
🍄
(2020/12/20 ひっそりと修正。 mintty, wsltty
はファイルに設定を書くのであった)。
はじめに.
この文書はEmacs Advent Calendar 2020の12/18(金)分の記事です。 昨日はfiboさんのemacs -nw のコピペ事情でした。 手元では gpaste + xclip で生活してますが、 …ネットワークごしのコピペは面倒そうですね。
さて。
最近Emacs絡みで頑張った事と言えば,
ターミナルでもall-the-icons.elしたくて,
isfit-plusを作ったぐらいだったので, 特に記事を書く気は無かったのですが,
Emacs JPのslack - emacs-jp.slack.com で行なわれた
オンライン宴会の終了時点で, 何故か 記事を書く ハメ 事になっていました。
元々, …「CUIのEmacsを再考」されたら, 何か書こうかと思ってたのですが…マダァ?(・∀・ )っ/凵⌒☆チンチン
閑話休題. 本記事では「ターミナルで立ち上げたEmacsで生活するため」に じたばたした内容についてまとめています。 幾分内容が不正確であったり, 怨念(?)のこもったポエムがあるかもしれませんが, ご寛恕下さいますよう, よろしくお願いいたします。
TL;DR
ターミナルで生活したい(emacs -nw
で生きていきたい)人は,
以下の3つを なんとかして 揃えておきましょう。
- ロケールが定義する文字幅, ターミナルが表示する文字幅
- フォントの文字幅
- Emacsが表示・カーソル移動に利用する文字幅
ターミナルでの生活
さて。
時を遡ること Emacs 22→23 の頃でしょうか? Emacs で XFT がサポートとされ, GUI においてアンチエイリアスの効いたフォント表示がされる様になりました。 自分の過去の日記を漁ると emacs22, emacs-snapshot(with xft) for etch なんてことを頑張っていたりしてますね。
しかし, 私はその後 GUI で Emacs を使う事は殆どなくなりました。
何故かと言えば,
入力中に文字の大きさや幅・高さがヒョコヒョコ変わって嫌だった
から, ですね。 入力している時に視線動かすのがストレスなんだよ。勝手に動くんじゃねぇよ。Wordかオマエは。
多分, アンチエイリアスで表示した上で,
global に variable pitch
な機能を無効化できたのであれば,
GUI を使っていたかもしれません(…誰かやりかたご存知ありませんか…?)。
結局どうしているのか, と言えば
「 emacs -nw
で生活する事にして, 表示は使っているターミナルに任せる」
という方法を取っています。
posframe? 何それ美味しいの?
pdf-tools? …便利そうですよね(´・ω・`)
というわけで普段使いのターミナルで幸せになりたいわけですが, これが非常に面倒臭い状況になっています。
Unicodeの闇(?) East Asian Ambiguous Width
もはや文字コードは UTF-8 なのが「普通」となりつつあります
( 偶に古いシステムで =ja_JP.eucJP= とか見て砂吐きますが )。
UTF-8はUnicodeの符号化の一つであり,
Unicodeといえば「全ての言語を単一の文字コードで表わす」という
バベルの塔 壮大な試みであることは
周知の通りだと思います(CJK統合漢字やUnihanなんかは割と有名な話題かもしれませんね..。)
さて, Unicodeにおいて, 現在でも我々(私?)を困らせている話題が East Asian Width のお話です。
- Unicode Standard Annex #11(UAX#11)
- 東アジアの文字幅
UAX#11 では(乱暴に言えば)文字の「幅」が半角幅か全角幅か が定められているのですが, 困った事に 文字幅が定まらない, 文脈に依存して文字幅が変わる 文字, East Asian Ambiguous character という文字が定義されています。 この文字(集合)の定まった経緯は
- 東アジア圏の文字コードでは文字幅が全角
- 東アジア圏以外では文字幅は半角(主にギリシャ文字やキリル文字など)
という歴史的事情(と互換性)を考慮して, なんですが…。
実際のところ libc6
の wcwidth
とか、特段文脈を考慮しません(いや、「文脈」って何ですかね)。
ロケールデータを参照して, そこにある通りに, East Asian Ambigous width は常に 1 が返ってきます。
というわけで, ターミナルで生活する際には, East Asian Ambigous Width は 常に全角(=2)である or 常に半角(=1)である かの選択を迫られます(少なくとも私は)。
ターミナル毎の対応
文字集合としての UTF-8 での文字幅は, ターミナルにおける「カーソルの横移動幅」の計算に必要不可欠です。 よって「文脈によって文字幅が変わる」とかシンドイので, 大抵は決め打ちです。 この実装はターミナルによって違います。
- libc6 を尊重するよ(それは libc6 の担当だよ) ⇒ rxvt-unicode
- libvte で文字幅を計算するよ ⇒ vte 系のターミナル: gnome-terminal など
- 自前で変更できるようにしておいたから設定書いてね
⇒ mlterm, mintty, wsltty
- (2020/12/20) mintty, wsltty はオプションじゃなくて設定ファイルでした.
- 切り替えオプション付けておいたから設定してね
⇒
mintty, wsltty, iTerm2 など - CJKV とか知ったこっちゃないよ ⇒ Windows Terminal
まあ, ターミナル内で統一して処理されていれば問題無い筈ですね。
とはいえ, 二文字幅派は苦労が耐えません。 例えば 面倒なのが Unicode の Box Drawing Char - 罫線素片です。 なんとこれは Ambiguous なので、 二文字幅派は (n)curses を表示に使う アプリケーションにおいて表示が大幅に崩れたりします。
NCURSES_NO_UTF8_ACS
という環境変数に 0 or 1 を
与えることで「崩れたり崩れなかったりしろ」と設定できる筈なんですが,
そもそもこの環境変数を読まないで独自に文字幅を判定していたり、
折角指定して VT100 の alternate character set(ACS)で表示する様にしても,
それをわざわざ Unicode の罫線素片に戻す(libvte系の)ターミナルもあったりして,
なかなかシンドかったりします。
結局どうするの?
現在, 私は「常に2文字幅」で生活しています。 普段使いのターミナル群は
- Linux では rxvt-unicode.
- Windows では wsltty (mintty)
- macOS では iterm2
です(どっかのタイミングで辛くなって「1文字幅」にするかもしれませんけど…)。
これらのターミナルのうち,
wsltty と
iTerm2 には East Asian Ambiguous Width に関する設定があります。
(2020/12/20 追記)
mintty,wsltty
は設定ファイルに書くことで挙動を変更できます
(ex. %APPDATA%\wsltty\config
に Charwidth=ambig-wide
と書く)。
また, rxvt-unicode はロケールデータを参照しているので,
自分の手元の環境ではロケールデータを書き変えています。
なお, 後述の uwabami/isfit-plus のデータ領域も 2 文字幅にしています。
…そうそう, みんな大好き tmux ですが
表示の文字幅の勘定にはロケールデータを使うことになったのですが,
何故か setlocale(LC_CTYPE, "en_US.UTF-8")
に決め打ちされています。
2文字幅派は辛いですね。
良い感じのフォントを求めて
ターミナルでの 1 文字幅派, 2文字幅派は決まりましたか? その設定は済ませましたか?
では次はフォントを決めましょう。 ターミナルが処理する幅を決めたのであれば, 表示に使うデータ, つまりフォントの幅も 1 文字 or 2 文字に揃えておかないと幸せになれません。
Nerd Font と PUA
1文字幅 or 2 文字幅が選べて視認性の高いフォントは既に幾つかあります (例えば, みんな大好き Ricty はデフォルト 2 文字幅派ですね。生成時にオプションで 1 文字幅にもできます)。 ついでに, ターミナルでの表示といえば, みんな大好きNERD FONTSがあります。 これで色々なアイコンを表示できて, ターミナル生活が捗ります。
ですが, NERD FONTS は Unicode の Private Use Area(PUA) 以外 も使っているので 例えば, 異体字が使えません。 「かつしか」区民や「かつらぎ」市民にごめんなさいしないといけない(かもしれません)し, 「わたなべ」さんや「さいとう」さんにもごめんなさいしないといない(かもしれません。 一応, PUA以外を使っている事は issue に上がっていて(Suggestion Fix invalid code points for some glyphs #365) いつか解決するのかもしれません(し, しないのかもしれません)。
一応, 上記 issue の plan 2 に従って修正したアイコンフォントを 公開してあります
ついでに, このフォントのアイコンを利用するための all-the-icons.el のデータセットも同梱していますので, 適宜御活用下さい。
Emacsでの「文字幅」
ターミナルでのカーソル移動幅と表示するフォントの幅が整理された所で,
ようやく emacs -nw
での話題です。
こちらもやることは単純で,
「Emacs での表示・移動幅をターミナルに揃え」ます。
具体的には
(aset char-width-table #x2661 2)
等の様に, 2文字幅で表示したいコードポイント(レンジ)を更新しておけば良いことになります。 拙作の uwabami/locale-eaw-emoji では locale-eaw-emoji.el としてまとめていますので, 適宜御活用下さい.
最後に
というわけで。
1文字幅の場合は PUA も 1文字幅に強制される事が多い(=アイコンフォントが使えない)のですよね。 この辺が解消されたなら, 1文字幅派に改宗するかもしれません。
「こんな苦労をせずに GUI 使えば?」という意見もあるかもしれませんが,
入力している時に視線動かすのがストレスなんだよ。勝手に動くんじゃ ry
明日は eggc さんの「ord-mode を使ったコード読むときの記録のとり方」の予定です。
参考文献
- 本日記内
- emacs22, emacs-snapshot(with xft) for etch: emacs22→emacs23 の頃のお話
- (解決) tmux で EAW二文字幅としてこの先生きのこるには
- all-the-icons-in-terminal
- Emacs JP
- Emacs JP の slack: emacs-jp.slack.com …お気軽にどうぞ!
- Emacs の素敵拡張あれこれ
- Unicode, East Asian Ambiguous Width あれこれ
- Youtube: 強いUnicode #kernelvm
- Unicode Standard Annex #11(UAX#11)
- 東アジアの文字幅
- 罫線素片
- ncurses: alternate character set: ACS
- ぼぎ〜てっく- ラベル:文字幅
- xterm, GNU screen, emacs23 の East Asian Ambiguous Width 対応
- tmux
- windows terminal
- 拙作
- uwabami/locale-eaw-emoji
- uwabami/isfit-plus
- uwabami/fsmrmp: Patched Font: ‘Fantasque Sans Mono’ + ‘Rounded Mgen+’
- ちなみに rxvt-unicode はフォントの ASCII の領域で文字幅を算出するので、 単なるアイコンフォントを使うと文字幅が勘定できません。 結構ハマる事多いんじゃないかなぁ…。
_ kudzu_naoki [トラックバックの送り方がわからなかったのでこちらから失礼します。 vendorについては丁度こないだ見てまわったとこ..]
_ iwamatsu [mikutter のキャラ=初音ミク ではないとのことです。なので問題ないです。けど、見た目があれなので@toshi..]