Posts

ちょっとしたCLI（ある程度出来たら記事にします）をOCamlで作っています。その際、初めてppx_letを使ってみたんですが、なかなか良かったので紹介します。 <!–more–> ppx_letは、OCaml界隈では知らない人のいないJane Street社が公開しているPPX拡張です。 OCamlでmonadを扱う時の課題 大抵、resultとかoption（特にresult）をmonadicにつなげていく時、大抵は下のような書き方になります。 let bind v ~f = match v with | Ok v -> f v | Error _ as v -> v let (>>=) v f = bind v ~f let foo = function | v when v > 10 -> Ok v | _ -> Error "error" let bar v = Ok (v * 10) let () = let v = foo 12 >>= bar in match v with | Ok v -> Printf.printf "result %d\n" v | Error e -> Printf.printf "error %s\n" e >>= とかのoperatorを使うのが一般的かと思います。これは非常にシンプルな例なので、operatorでも特に困りません。 しかし、ある程度の規模になってくると、ある時点で取得したデータを、後に使いたい、ということが非常によくあります。 foo v >>= fun v1 -> bar v1 >>= fun v2 -> foobar v1 v2 これが続くと、特にreadabilityの点で問題になってきます。 ...

最近、React＋TypeScriptの開発環境を作る場合、大抵はcreate-react-appを利用するケースが多いと思います。 実際、種々のベストプラクティスであったり、単純にアプリケーションを作る方にフォーカスする場合、create-react-appを利用するのがbetterです。ただ、色々な要因でejectせざるを得ない状況に追い込まれると、結構厳しいケースが多いです。実際公式でもejectは非推奨です。 そういうときに備えて（？）、０から環境を作ってみましょう。こういう経験をしておくと、ejectすること無くいろいろすることが出来ます。 <!–more–> 今回作っていって見る環境は、次のような環境です。 React + TypeScriptで書ける TypeScript内では、moduleは相対パスではなく、 @/hoge のようにしてアクセスできる TSXで書ける ESLintでlintできる prettierでformatting Jest＋enzymeでユニットテスト webpack-dev-serverでhot reloading Componentのreloadは色々問題もあるのでやりません Reactの導入 まず新しいpackageを作りましょう。ここでは react-handmade-sample という名前で作ります。 $ mkdir react-handmade-sample $ cd react-handmade-sample $ npm init 次に、React関連のパッケージをインストールします。styled-componentsは趣味なので、無くてもいいです。 $ npm install react react-dom styled-components Webpackの導入 Webpackは、現時点でデファクトbundlerです。非常に設定量が多いと思われがちですが、必要最小限であれば、意外と量は少ないです。とりあえず必要なので入れます。webpack-dev-serverもついでにいれます。 $ npm install webpack webpack-dev-server $ npm install html-webpack-plugin tsconfig-paths-webpack-plugin Webpackは、developmentの場合に使う基本設定と、production時に利用する設定の二通りを用意しますが、とりあえずはdevelopmentの設定だけ記述します。 // webpack.config.js const path = require('path'); module.exports = function(isProduction) { return { mode: "development", entry: path.resolve(__dirname, "./src/index.tsx"), // ファイルの出力設定 output: { // 出力ファイルのディレクトリ名 path: path.resolve(__dirname, 'dist'), // 出力ファイル名 filename: "index.js" }, module: { rules: [ ] }, resolve: { extensions: [".ts", ".tsx", ".js", ".json"], plugins: [ ] }, plugins: [ ] }; }; 空っぽに近いですが、とりあえず最小限です。 ...

人事／総務の業務上の問題を解決するために、APIを作ろうということになりました。せっかくなのでOpenAPI3を使おうぜ、となったんですが、Swagger2と構成が違っていて、テンプレートをいじるときにどういう値を視ればいいのか・・・がわからんかったです。 <!–more–> それをどう見ればいいか、のメモ書きです。 まず見るリポジトリ https://github.com/OpenAPITools/openapi-generator.git OpenAPI3のSpecifiationから、Server/Clientの生成をするための公式ツールです。jarが提供されているので、Javaが動けばだいたい動きます。 Swaggerのときも同じものがありましたが、OpenAPIに分化してからorganizationも分離しています。このGeneratorは各種言語のClient/Serverを生成するため、各言語用のテンプレートが置かれています。 各言語のテンプレート https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources リポジトリ上のリソース内に、各言語/フレームワークごとに分かれています。ここにテンプレートがありますが、このテンプレートの中を見ても、使われてる変数はわかりますが、 どういう値を使えるか はわかんないです。 実際、ここはテンプレートだけなので、これを利用して生成している場所は別にあります。 各言語の生成箇所 各言語ごとのCLIはここで定義されています。ただ、これを見ても、どのテンプレートを使うんだ？ということしかわかりません。 https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages 実際にテンプレートに値を注入している場所はここです。 https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultGenerator.java この中の、 generateApis というメソッドの中で定義されています。基本的にOpenAPI3のYAMLから取得できる情報はここから取得できます。なので、ここを見ると、自分のテンプレートで使いたい値が見つかる・・・かもしれません。 メモ書きもしていく宣言 簡単に見つかるだろー、ってなったら見つからなかったのと、デフォルトの提供されているテンプレートだと思ったものと違う可能性もあるので、テンプレートを編集するための第一手として。私を含め誰かの参考になれば・・・。 OpenAPI3だとSpringFoxでSwagger2の形式で吐き出せない、みたいなのもありますので、Swagger2を使い続けるか、OpenAPI3を使うかは計画的に。 気づいたら7月が終わりそうです。ブログをもうちょっと書いていきたいので、お手軽にかけそうなものがあれば書いていきたい所存。

最近人事／総務からのヒアリングした業務上の問題を解決していく、という社内プロジェクトに参加しています。 その中で、割と調べても出てこなかった事柄をメモしておきます。 <!–more–> 要望 今回解決したいのは、次のような問題でした。 色々な事情で、Excelから紙で印刷いないといけない 親会社の意向とかいろいろあるようで Excelの数が多い だいたい社員数くらいある（現状だと300↑） 印刷するのが手作業で辛い しかもそういう業務がけっこうある とにかく問題としては、 Excelを開く→最初のページだけ印刷する という業務が多く、かつ時間がかかる、と。電子承認とかそういう方向に行きたいらしいですが、まーいろいろ事情があるようで。 方針の検討 とりあえず抜本的ではないが、ある程度作る労力と、結果の省力化に貢献できるものとして、次のようなツールを作ることにしました。 Excelマクロの実行が必須 実行しないと正しい状態にならないので・・・ Excelの １ページ目だけ 印刷できる フォルダ内のExcelを一気に印刷できる 任意のフォルダでやりたい 困ったこと 人事／総務の方々は、ITレベルが様々なので、Windows標準で入っているものを使う、ということで、 PowerShell を使うことにしました。 ところが、いろいろ調べて（ググって）みても、 ExcelからBookを印刷する というものはあっても、 指定したページだけ印刷する ということをやっている人がまずいないっぽいという・・・。 フォルダ内のExcelを印刷するという回答 色々試す 色々試した所、次のサイトが気づきになりました。 https://docs.microsoft.com/ja-jp/office/vba/api/excel.workbook.printout このページ、Office VBAのヘルプですが、ここに引数が書いてあります。 名前 必須 / オプション データ型 説明 From 省略可能 Variant 印刷を開始するページの番号を指定します。 この引数を省略すると、最初のページから印刷します。 To 省略可能 Variant 印刷を終了するページの番号を指定します。 この引数を省略すると、最後のページまで印刷します。 Copies 省略可能 Variant 印刷部数を指定します。 この引数を省略すると、印刷部数は 1 部になります。 Preview 省略可能 Variant True の場合、印刷をする前に印刷プレビューを実行します。 False、または省略した場合、直ちに印刷を行います。 ActivePrinter 省略可能 Variant アクティブなプリンターの名前を指定します。 PrintToFile 省略可能 Variant True の場合、ファイルへ出力します。 引数 PrToFileName が省略された場合、出力先のファイル名を指定するためのダイアログ ボックスを表示します。 Collate 省略可能 Variant True の場合、部単位で印刷します。 PrToFileName 省略可能 Variant _PrintToFile_がTrueに設定されている場合、この引数は印刷先のファイル名を指定します。 IgnorePrintAreas 省略可能 Variant True の場合、印刷範囲を無視してオブジェクト全体を印刷します。 これをPrintOutに指定すればいいんじゃね！？ということで、こんな感じにしてみました。 ...

だいぶ前ですが、Tensorflowのメジャーバージョンアップである2.0のbetaがリリースされました。丁度いいので、以前作ったまま放置していたツールを更新してみようと思います。 <!–more–> 以前作ったのはこれです。Qiitaで記事も書きました。 https://github.com/derui/painter-tensorflow https://qiita.com/derui/items/fe232c87d981d241ae07 https://qiita.com/derui/items/9719efa14f44a792362b 大雑把に言うと、着色済みの画像から線画を抽出するものと、その逆版です。現在ではこういう個人レベルのおもちゃではなく、実際にサービスとして運用されてるものもありますね。 1. まず公式サイトを確認する 2.0-betaをインストールする方法は、公式サイトに載っています。ちゃんと確認しておきます。 https://www.tensorflow.org/install また、今回対象にするものは、GPUが大前提なので、CUDAとかの条件も確認しておきます。このへんがしんどいので、普通はGoogle Colabとかを利用するのが良いかと。私は裏側の学習も兼ねてやっているので、頑張って整えていきます。 https://www.tensorflow.org/install/gpu 2. CUDAとかを色々用意する 他のツールは触ったことがないのでなんとも言えませんが、TensorflowはかなりアグレッシブにCUDAのバージョンアップを行っている印象です。実際、2.0-betaでは以下を要求してきました。 Hardware requirements The following GPU-enabled devices are supported: NVIDIA® GPU card with CUDA® Compute Capability 3.5 or higher. See the list of CUDA-enabled GPU cards. Software requirements The following NVIDIA® software must be installed on your system: NVIDIA® GPU drivers —CUDA 10.0 requires 410.x or higher. CUDA® Toolkit —TensorFlow supports CUDA 10.0 (TensorFlow >= 1.13.0) CUPTI ships with the CUDA Toolkit. cuDNN SDK (>= 7.4.1) (Optional) TensorRT 5.0 to improve latency and throughput for inference on some models. ...

最近家に帰ってからめっきりプログラミングをしなくなってしまいました。いろいろやることがあると同時並行では難しいですね。 さて、今回はmozcの候補表示pluginを作ってみたというお話です。 <!–more–> https://github.com/derui/mozc-posframe mozcの候補表示は、標準で存在する Echo Areaへの表示、overlayでの表示のほか、 mozc-popup という拡張があり、大抵はこれを利用している方が多そうです。私もこれを利用していました。 （Emacs上での日本語入力にfcitxとかを利用している人は対象外です。そういう人のほうが多いんだろうか・・・） mozc-popupの利点 mozc-popupを利用していたのは、やはり利便性を重視してのことでしたが、特に以下の点がキーだったと思います。 変換位置と候補が近い overlayでもだいたい一緒ですが 実績あるpopup.elの利用 Spacemacsから入った人は知らないかもしれない、auto-completeで熟成したpopup表示に特化したlibraryです この結果、標準のoverlayよりも高速でした だんだんででくる問題点 mozc-popupを利用する前は、mozc + popupという組み合わせで長年使っていましたが、最近色々と問題が見えるようになってきました。 org-modeとpopup.elの相性が悪い 新しい拡張を作ることにした最大の契機 特に多数の折りたたみがあるときに顕著で、表示までの時間や、表示の崩れが非常に激しかった popup.elの更新頻度 一時代を築いたpopup.elですが、companyが台頭してからはだいぶ表舞台から消えてしまった感があります その仕組み上も複雑で、メンテナンスが困難だという話も child frameという潮流 Emacs 26から、frameに大きな拡張が入り、child frameと呼ばれる形態が可能になりました。端的に言うと、frameをfloating windowとして扱うことができる、というものです。 すでに様々なライブラリで利用されており、名実ともにEmacs26の目玉機能となっています。（個人の観測範囲では） https://github.com/sebastiencs/company-box https://github.com/emacs-lsp/lsp-ui しかし、あくまでframeを扱うものであるため、そのままだとpixel単位での操作が必要となり、非常に煩雑です。WIN32 APIでwindow作っていた時代になった気分です。それをラッピングしたlibraryが、 posframe です。 mozc + posframe 前述したmozc-popupの問題は、つまるところoverlayでの表現に限界があった、ということに尽きると思います。overlayはあくまでtextのpropertyでしかないので、複数のoverlayが設定された場合、その時時で異なる問題が出るであろうことは想像に難くありません PCで日本語を入力する場合、大抵はIMEを使うかと思います。Windows/macOS/Linux いずれも、候補表示そのものは 独立したWindow です。つまり、Child frameをこの用途に使うと丁度いいんじゃないか？というのは前々から考えていました。 すでにあるだろうと探してもなかったので自作することにしたわけですが。 mozc-popupとの比較 Pros org-modeやそれ以外でも、候補表示の時間がほぼ一定 調整の余地はありますが 表示崩れがない これがposframeを利用する最大の利点です 独立したframeを表示しているだけなので、複数のoverlayが設定されることに起因する問題から開放されています Cons install方法が煩雑 melpaとかに入っていないので、どうしてもstraight.elとかが必要です Emacs26以上 + GUIでないと動かない 個人的に、端末上で利用するのはもはや趣味の領域でしかないと思ってます 描画性能もほとんどの場合GUIツールキットの方が早いし、ChildFrameは性質上GUIでしか動きません 端末しかない？諦めてVimった方が幸せになれるかと・・・ ありがとう、mozc-popup mozc-posframeは、mozc-popupのソースを7割くらい流用しています。mozc-popupがなければ、そもそもmozc-posframeを作ろうと思ってなかったと思います。 まだmozc-posframeは若干のバグや性能向上の余地がありますが、すでに常用できるものになっている（というか常用してる）と思うので、よければ利用してみてください。

せっかくの個人ブログなのでこんなものも書いてみます。レビューというか感想ですね。 <!–more–> SEKIRO -SHADOWS DIE TWICE- （PS4版。以下SEKIRO）のプラチナトロフィー取得が終わったので、感想を書いてみます。完全に個人的な感想ですので、仮にこれを読んで買って満足できなかったとしても保証はできかねます。ご了承を。 なお、完全にプラチナ狙いで行ったので、3週目で終了しています。 書いている人間のスペック 前提として、この記事を書いている人間のゲーム的スペックを書いておきます。ライトではないがガチでもない、という普通の領域だと思います。 Demon’s Soul/Dark Soul(1のみ)/Bloodborneクリア経験あり 基本PS4/PCのゲームが主 やり込むというよりはトロフィー狙いが多い 最初の一周は一切攻略サイトとかを見ない、がポリシー どんなゲーム？ 死ぬことを楽しむゲームです なんの説明にもなっていないですね。ちゃんとした紹介は↑の更新サイトを見たほうが早いと思います。Demon’s Soul/Dark SoulやBloodborneをプレイしたことがある方であれば、ああいう感じ、と言えば伝わるでしょうか。SIEとFROM Softwareが手を組んだ作品です。ちなみに SEKIRO は せきろ と読むのが公式だそうです・・・ほんとか？ すっかりSoulライクゲームがFROM Softwareの代名詞になりましたが、30代くらいの人にとっては FROM Software＝アーマードコア とかなんじゃないでしょうか。もうアーマードコアが出ることはなさそうですが、もう一回プレイしてみたいものです。 閑話休題。 さて、Soulライクゲームと同じような感じ、と書きましたが、その内容は大きく異なります。同じなのは死んで覚える、というくらいです。私は最初の一周は公式サイト以外を見ないことにしているので、死にっぷりに拍車がかかります・・・。が、できればSEKIROやSoulライクゲームは最初だけは攻略サイトとかを見ないようにするのをおすすめしたいです。そのあたりは個人の裁量なので、最初からガッツリ見るも詰まったら見るも自由ですが。 SEKIROとSoulライクゲームの違い 簡単に箇条書していきます。 レベル概念の撤廃 Dark Soulとかでは、キャラクターの成長自体が個性になりますが、SEKIROでは成長要素は2つしかありません また、大抵のスキルは プレイを楽にする のではなく、 多様な攻略 を可能にするものなので、これを取ると楽になる！というのはあんまりないです 武器・防具の概念がない 最初っから最後まで装備は一緒です。アイテムで一時的に変更する以外、防御力を上げる手段は（把握している限り）ありません スタミナの概念がない 忍者なので 回避し放題、ダッシュし放題、攻撃し放題です 移動の自由度が圧倒的に高い 鉤縄のおかげで、探索が非常に楽しいです。 致命の一撃を狙うのが基本 HPを削り切る、というパターンは多くないので、特に雑魚戦における戦闘のテンポが非常に早いです ソウルの回収的な要素がない 死んだらそのタイミングできっちり経験値とかが半分になります 救済措置はありますが、あんまり期待しないほうがいいです 要素としては色々ありますが、とにかくゲーム内の要素が 剣を交えること に特化されている感じです。 キャラクターの成長＝自分の成長 Soulライクゲームでは、ある程度はレベルを上げてゴリ押し、ということができました。しかし、前述したとおり、SEKIROではレベルという概念がありません。アイテムを利用しないと、キャラクター自体の成長はありません。そして、そのアイテムは一部を除いて ボスを倒さないと取得できません 。 つまり、ボスで詰まった場合、 自分自身の腕を上げないと攻略できません 。ここでの腕は、相手のパターンを見切る、ということも含みます。この点がSoulライクゲームとの一番の相違でしょう。 逆に言うと、ボスに勝てた＝自分が成長した、ということにほかなりません。特に大ボスは、トドメにイベント的な最後の一撃が必要なんですが、それを行う＝勝利なので、イベント的な演出も含めて 勝利した瞬間の快感は凄まじいです （個人差あり）。 その快感を得るために、次のボスに向かってまた何度も死ぬ・・・と繰り返すことになります。その過程で、ベースになる腕も上がっていきます。 剣戟 を体感する 弾きと体幹システム上、基本的には攻め続けて、相手の攻撃は弾き（＝ジャストガード）し続ける、というのが理想です。そこに至るまでには何度も死ぬことになりますが・・・。逆に、そこに至ると、まさに映画のような剣戟を繰り広げることができます。これがまた気持ちいいんです。 ...

去年の12月くらいから、KotlinでAPIサーバーとバッチを含むアプリケーションを業務で作っていました。その感想を書いていきます。 <!–more–> 本題の前に閑話を。世間から１週遅れくらいで、 SEKIRO -SHADOWS DIE TWICE- をプレイしており、この間一周目が終わりました。私は一周目では攻略サイト等は見ないことにしているので、クリアと同時に解禁してみた所、一周目で出したエンドがなかなか厳しい（他のルートより短く、アイテムとかが集まりきらない）ものだと発覚・・・。若干バッドっぽい選択肢ではあったんですが、まさかそういったものだとは思わず。おかげで二週目が厳しいものとなっております。 複数周回がありそうな選択肢だと、バッドっぽいのから選択する癖があるんですが、それが仇となりました。まぁ、二週目を進めている感じ、明らかにPlayer Skillが高まっており、思ったよりも苦戦はしていないのですが。 閑話休題。 環境の前提 今回作ったアプリケーションは、既存のアプリケーションの完全作り直しなんですが、肝心の既存アプリケーションが PL/SQL で出来ており、完全新規に当たっては DDD を試験的に取り入れています。 Middleware/Framework 利用しているMiddleware/Frameworkは次のような感じです。 Spring Boot 言わずと知れた。 Spring Batch バッチを作成する必要があったので MySQL 現場ではだいたいこれのようでした。 Kotlin 今回の主役 jOOQ ORM。Oracleに接続する場合はcommercial licenceが必要なので注意（繋げなかった人） Gradle 大分こっちを選ぶ人が増えた印象 アーキテクチャ Clean Architecture とDDDを併用しています。Clean Architectureは、とりあえず原典に従って分割している感じですが、現状あまり困っていないです。ここについてもいつか書ければ。 プロジェクト構成 Gradleのmulti project構成を利用して、DomainやGatewayなどの依存方向を強制しています。DDDを実践する上で、Domainに余計な依存を入れないことが重要だと思っているので、これは結構おすすめです。プロジェクトは次のように分割しています。 domain usecase api batch infrastructure 依存関係は以下のようになっています。domainプロジェクトは、 test以外に外部依存ライブラリがない という状態になっています。 domain <-- usecase <- api └- batch Kotlinの適用範囲 全部 です。設定がめんどくさくてJavaになっているものも１ファイルくらいありますが、99.9% Kotlinで書いています。 Kotlin + SpringBootの感想 感想と言っても特筆すべきものはなく、あえて言えば 普通 です。Spring自体がKotlin対応を行っているということもあり、実に普通な書き心地です。 ただ、DIをしまくる関係上、関数で済むようなものでもinterfaceにしないといけないので、その点がストレスです。 @Component class Foo(private val bar: () -> String) { fun exec() = bar() + "test" } みたいなクラスがあったとき、関数をDIすることが出来ない（多分）ので、わざわざinterfaceを定義する必要があります。 ...

いろいろ書くネタを探しているうちに4月になってしまったので、3月にやったEmacs改善について書いてみようかと思います。結構量が多くなったので、分割します。 <!–more–> なお、かなりの部分で Emacsモダン化計画 -かわEmacs編- を参考にさせていただきました。私の.emacs.dはGithubにおいてあります。 https://github.com/derui/dot.emacs.d doom-modeline + all-the-icons doom-modeline all-the-icons 最初に入れたパッケージです。modelineが一気にかっこよくなりました。all-the-iconsでは色々調べましたが・・・。 (use-package all-the-icons :custom (all-the-icons-scale-factor 1.0)) (use-package doom-modeline :commands (doom-modeline-def-modeline) :custom (doom-modeline-buffer-file-name-style 'truncate-with-project) (doom-modeline-icon t) (doom-modeline-major-mode-icon nil) (doom-modeline-minor-modes nil) :hook (after-init . doom-modeline-mode) :config (line-number-mode 0) (column-number-mode 0) (doom-modeline-def-modeline 'main '(bar workspace-number window-number evil-state ryo-modal xah-fly-keys matches buffer-info remote-host buffer-position parrot selection-info) '(misc-info persp-name debug minor-modes input-method major-mode process vcs checker))) なお、全体的にuse-packageを利用しています。 which-key which-key ...

最近 Emacsモダン化計画 -かわEmacs編- を参考にしつつ、しばらくいじっていなかったEmacsをいじっています。しかし、all-the-iconsを導入したときに、アイコンが色々？な感じになってしまいました。 原因を探ったり何なりで解決できたので、備忘録として残しておきます。 <!–more–> 発生していた事象 普段Emacs上ではCicaフォントを使っています。以前はRictyを利用していましたが、Rictyよりもこちらのほうが好みだったので、1年くらい前から愛用しています。 https://github.com/miiton/Cica ところが、Cicaを利用している環境でall-the-iconsを有効にしたら、色々と問題が発生しました。スクショは撮っていなかったので画像はありませんが、次のような状態でした。 doom-modelineのアイコンが明らかにおかしい 保存アイコンが gopher になってたり、gopherのアイコン自体が違ってたり Gitのアイコンが地球儀になってたり アイコンのサイズが色々おかしい all-the-iconsのアイコンを全部表示すると、明らかに別のアイコンが表示されている という感じで、もう完全に何かが干渉していることは明らかでした。 調査 だいたいまずいのはフォント設定周りだろうと、使っているフォント設定自体を無効化すると、うまい具合に表示できました。これから、以下のような仮定を立てました。 追加で行っている設定では、 create-fontset-from-ascii-font で作ったものに set-fontset-font していた set-fontset-font の範囲は 'unicode だった＝all-the-iconsで利用している範囲を上書きしていた？ 仕様上、一回設定したものを上書きできないっぽい＝Cica側の特徴に原因が？ ここまでで、大体Cicaに設定されている絵文字部分とall-the-iconsが干渉している、と判断しました。 解決した 最終的には、Cicaから絵文字を除いたバージョンに切り替え、フォント設定を以下のようにしました。 (defun my:font-initialize () "Initialize fonts on window-system" (interactive) (cond ((eq window-system 'x) (let* ((size my:font-size) (asciifont "Cica") (jpfont "Cica") (h (round (* size 10))) (jp-fontspec (font-spec :family jpfont))) (set-face-attribute 'default nil :family asciifont :height h) (unless (string= asciifont jpfont) (set-fontset-font nil 'unicode jp-fontspec nil 'append)) (when (featurep 'all-the-icons) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-alltheicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-material-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-fileicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-faicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-octicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-wicon-family)) nil 'append)) (message (format "Setup for %s with %f" asciifont size)))) (t (message "Not have window-system")))) この設定を、after-init-hookで実行しています。元々asciiとjpで異なるフォントを利用していた名残の設定だったので、整理しました。普通にset-face-attributeだけでいいんじゃないの？と思われるかもしれませんが、部屋のデスクトップと現場のラップトップでフォントサイズを切り替えられるようにしているので、若干複雑な設定をしています。 ...