「テスト駆動開発による組み込みプログラミング」のサンプルコードをCppUTestで実行する
Table of Contents
「テスト駆動開発による組み込みプログラミング」のサンプルコードをCppUTestで実行する :CPPUTEST:
前回の記事で、CppUTest を導入しました。今回は、TDD本 （「James W. Grenning （蛸島昭之監訳）. テスト駆動開発による組み込みプログラミング.オライリー・ジャパン」）で使われているサンプルコードをWEBより入手して実行してみます。使うのは MSYS2環境です。
とりあえず実行はできましたが、ダウンロードしてきたビルド環境はそのままでは使わず、サンプルコードだけをコピーしてシンプルな環境を自分で作って勉強した方がよいという印象を持ちました。
サンプルコードの入手先
上述の本で使われているサンプルコードは、オライリーの本の紹介ページからジャンプした以下のURLからダウンロード可能です(2022.6.18時点)。
参考： https://pragprog.com/titles/jgade/test-driven-development-for-embedded-c/
ビルド
上記の入手先で jgade-code.zip というzipファイルが入手できますので、これを解凍します（次のようなファイル構成になっています）。
# # ls
.cdtproject .cproject .gdb_history .project .settings/ BookCode.dsw docs/ include/ lib/
Makefile MakefileCppUTest.mk MakefileUnity.mk mocks/ README.txt SandBox/ scripts/ src/ t0/ t1/
t2/ t3/ tests/ unity/ unity.framework/
このディレクトリ中にある、README.txt を見ると、最初はt0（ディレクトリ）から始めるのがいいよ、って書いてあります。とりあえず t0 ディレクトリに行ってビルドを試してみます。
Build all examples
cd <BookCodeParent>/code
make everything
If there are problems, you will probably want to build only
one directory at at time. code/t0 is a good place to start.
t0 ディレクトリに行くと、次のようなファイルがあります。Makefile が用 意されているのでビルドできそうです。また、srcディレクトリ以下には、 LightScheduler.c や RandomMinute.c といった本を持っている人なら、あー あれね、ってわかるファイルがおいてあります。
# # ls
.cproject .project include/ lib/ Makefile mocks/ objs/ src/ t0.dsw tests/ unity/
早速、makeを実行してみます。残念ながらエラーが出ました。
※ CppUTest を使うために、CPPUTEST_HOME を環境変数に設定しておきます。
# # make
compiling AllTests.cpp
compiling LightSchedulerRandomizeTest.cpp
compiling LightSchedulerTest.cpp
compiling RandomMinuteTest.cpp
compiling FakeTimeServiceTest.cpp
compiling LightControllerTestSpy.cpp
compiling FakeRandomMinute.c
In file included from C:/home/share/cpputest/cpputest-latest/include/CppUTest/MemoryLeakDetectorMallocMacros.h:12,
from <command-line>:
C:/home/share/cpputest/cpputest-latest/include/CppUTest/CppUTestConfig.h:264:14: error: ISO C90 does not support 'long long' [-Werror=long-long]
264 | typedef long long cpputest_longlong;
| ^~~~
C:/home/share/cpputest/cpputest-latest/include/CppUTest/CppUTestConfig.h:265:23: error: ISO C90 does not support 'long long' [-Werror=long-long]
265 | typedef unsigned long long cpputest_ulonglong;
| ^~~~
cc1.exe: all warnings being treated as errors
make: *** [/c/home/share/cpputest/cpputest-latest/build/MakefileWorker.mk:525: objs/mocks/FakeRandomMinute.o] エラー 1
C90 にかかわるエラーらしいです。Makefile の中をみると、コンパイルする ときの引数が, ”-std=c89” となっているのでこれが原因と思われます。
そこで、次のように Makefile を書き換えます。
#CPPUTEST_CFLAGS += -std=c89
CPPUTEST_CFLAGS += -std=c11
※gcc の -std オプションで規格を選択できます。
※CppUTest をソースコードからビルドしたときに作られる、 "（インストール先ディレクトリ）/build/MakefileWorker.mk" の中に,CPPUTEST_USE_LONG_LONGというマクロがあります。このマクロを設定すればこの変更は不要かもしれません（未調査）。
修正した後に再度 make を再実行してみます。C90 にかかわるエラーは抜けたのですが、今度は以下のようにとなり、ターゲットを make するルールがない、というエラーが発生しました。
# # make
compiling AllTests.cpp
compiling LightSchedulerRandomizeTest.cpp
compiling LightSchedulerTest.cpp
compiling RandomMinuteTest.cpp
compiling FakeTimeServiceTest.cpp
compiling LightControllerTestSpy.cpp
compiling FakeRandomMinute.c
compiling FakeTimeService.c
compiling LightControllerSpy.c
compiling LightScheduler.c
compiling RandomMinute.c
Building archive lib/libt0.a
a - objs/src/HomeAutomation/LightScheduler.o
a - objs/src/HomeAutomation/RandomMinute.o
make: *** 't0_tests' に必要なターゲット '/c/home/share/cpputest/cpputest-latest/lib/libCppUTest.a' を make するルールがありません. 中止.
CppUTest のライブラリである libCppUTest.a は make する必要がないので普通ならターゲットファイルにしないはずなのになんで？、って感じです。
※著者は CppUTest の開発者の一人みたいなのでこの本のサンプルコードを著者が作るときに、CppUTest そのものをビルドする環境で作成したのではないか、なんて気がしています。
仕方がないので、Makefile に空のターゲットファイルを追記します。
$(CPPUTEST_LIB):
# ←ここはTAB
これでようやくビルドが通るようになり、テスト実行ファイル（t0_tests.exe）が作成されました。
実行結果
makeすると、次のような結果が出力されます。
※OK、のところが t0_tests.exe の実行結果。
compiling AllTests.cpp
compiling LightSchedulerRandomizeTest.cpp
compiling LightSchedulerTest.cpp
compiling RandomMinuteTest.cpp
compiling FakeTimeServiceTest.cpp
compiling LightControllerTestSpy.cpp
compiling FakeRandomMinute.c
compiling FakeTimeService.c
compiling LightControllerSpy.c
compiling LightScheduler.c
compiling RandomMinute.c
Building archive lib/libt0.a
a - objs/src/HomeAutomation/LightScheduler.o
a - objs/src/HomeAutomation/RandomMinute.o
Linking t0_tests
Running t0_tests
.............................................
OK (45 tests, 45 ran, 407 checks, 0 ignored, 0 filtered out, 1 ms)
その後とまとめ
同様にして t1, t2, t3ディレクトリのコンパイルをしたのですが、同様のエラーの他、サンプルコードも、”;がない”、といった単純なエラーが出ました（まじか・・・）。
ダウンロードしてきたサンプルコードおよび実行環境はすぐにビルドできると思ったのですが、それなりにエラーに対処しなければいけないようです。
単体テストのお勉強がやりたいことであって、サンプルコードのビルドを通すのが目的ではないのでダウンロードした環境を使ったビルド作業は中断することにしました。
もちろん環境そのもの作り方は大変参考になりますし、コード中のバグも軽微なものなので役には立つと思います。とはいうものの、お勉強がしたい人は単純化した makefile を自分で作り直した方がよいかもしれません。
CppUTest を導入してみる
Table of Contents
CppUTest を導入してみる :CppUTest:
最近、Google test を導入したばかりなのですが、TDD本 （「James W. Grenning （蛸島昭之監訳）. テスト駆動開発による組み込みプログラミン グ.オライリー・ジャパン」）を購入して、その中でCppUTestがツールとして 使われていました。
本に載っているサンプルコードもビルド環境付きでダウンロード可能だった ので勉強にはいいかな、っていうのと、組み込み系で使えそうなので CppUTest もありですね。
というわけで先日インストールした GoogleTest に加えて CppUTest の環境 も立ち上げます。
CppUTest のインストール（MSYS2環境）
pacman によるインストール
本家（ https://cpputest.github.io/ ）ではソースからビルドする手法が示されているのですが、MSYS のパッケージインストーラでインストールできそうだったので深く考えずにインストールしてみます。
$ pacman -S mingw64/mingw-w64-x86_64-cpputest
とりあえずインストールは成功。c:/msys64/mingw64/lib の下に、 libCppUTest.a, libCppUTestExt.a が作られているので大丈夫。
インクルードファイルも C:\msys64\mingw64\include\CppUTest 以下に展開されています。
本家のソースコードからビルド
上述の本で使われているサンプルコードは、オライリーの紹介ページからジャンプした以下からダウンロード可能です(2022.6.18時点)。
参考： https://pragprog.com/titles/jgade/test-driven-development-for-embedded-c/
中身をみればわかるのですがソースコードのみでなくビルド環境一式が入手できます。著者はCppUTest開発者の一人らしいのでサンプルコードのビルド環境はCppUTestの開発環境に依存してそうな雰囲気なのが見て取れます。
なので、本家のソースコードからCppUTestをMSYS2環境でビルドして、使え るようにしてみます。
※諸々の事情で MSYS2 環境で使わないといけないところが正直足かせなので す・・・。
入手先はこちらです。
参考： https://cpputest.github.io/
本家の README.md に
You'll need to do the following to get started:
Building from source (unix-based, cygwin, MacOSX):
git clone git://github.com/cpputest/cpputest.git
cd cpputest_build
autoreconf .. -i
../configure
make
You can use make install if you want to install CppUTest system-wide
と書いてあるのでこの通りにやってみます。
git clone するでも、zip で入手するでもどちらでもいいので適当なディレク トリに展開します。
展開したディレクトリの下に "cpputest_build" というビルド用のディレク トリがあるのでそこに移動し、autoreconf を実行します。
・・・って、自分の環境にはなかったので autotools を pacman でインストー ルします。
※環境によってはインストールが不要だったり、逆に他のパッケージをインス トールしなければならないかもしれません。でも、都度必要なパッケージを pacman を使ってインストールするだけです。
# pacman -S mingw64/mingw-w64-x86_64-autotools
改めて autoreconf を実行すると、無事に configure が生成されました。 いつくも warning は出ていますが、obsolete（廃止）にちなんだものっぽい ので気にしないことにします。
# autoreconf .. -i
configure.ac:11: warning: The macro `AC_LIBTOOL_DLOPEN' is obsolete.
configure.ac:11: You should run autoupdate.
m4/ltoptions.m4:113: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:11: the top level
（～中略～）
../autoconf-2.71/lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
../autoconf-2.71/lib/autoconf/general.m4:1534: AC_ARG_ENABLE is expanded from...
configure.ac:418: the top level
次に configure の実行。標準出力に以下のようなログが出力され、 Makefileが無事生成されました。
いくつかのオプションが no になっていて使えないですが初学者の私がすぐ に使うことはないでしょうし、必要になったら使えるようにすればいいだけな のでOKとします。
# # ../configure
configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
（～中略～）
CppUTest Version 4.0
Current compiler options:
CC: gcc
CXX: g++
CC version: 11.3.0
CXX version:
LD: C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
Default CFLAGS: -g -O2
Default CXXFLAGS: -g -O2
CppUTest CFLAGS: -Wno-c++11-long-long -Wno-long-long -Wall -Wextra -Wshadow -Wswitch-default -Wswitch-enum -Wconversion -pedantic -Wsign-conversion -Wstrict-prototypes -Wno-disabled-macro-expansion -Wno-padded -Wno-reserved-id-macro -Wno-keyword-macro
CppUTest CXXFLAGS: -nostdinc++ -Wno-missing-exception-spec -include ../include/CppUTest/MemoryLeakDetectorNewMacros.h -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-c++14-compat -Wno-c++11-long-long -Wno-long-long -Wall -Wextra -Wshadow -Wswitch-default -Wswitch-enum -Wconversion -pedantic -Wsign-conversion -Woverloaded-virtual -Wno-disabled-macro-expansion -Wno-padded -Wno-reserved-id-macro -Wno-keyword-macro -Wno-global-constructors -Wno-exit-time-destructors -Wno-weak-vtables -Wno-old-style-cast
CppUTest CPPFLAGS: -include ../include/CppUTest/MemoryLeakDetectorMallocMacros.h -I ../include
CppUTest LDFLAGS:
CppUTest LIB: -lpthread
Features configured in CppUTest:
C++ standard used: default
Memory Leak Detection: yes
Compiling extensions: yes
Use Long Long (if available): yes
Disable CppUTest compile/link flags: yes
Address sanitizer: no
Using Standard C++ Library: no
Using Standard C Library: yes
Generating map file: no
Compiling w coverage info: no
----------------------------------------------------------------
次はmakeの実行。
無事に、libCppUTest.a、libCppUTestExt.a が生成された他、CppUTestで利 用できるスクリプト類も展開先のディレクトリに格納されています。本家の README.md で紹介されている通りの方法で msys2 環境でもビルドできました。
# # make
make all-am
make[1]: ディレクトリ '/c/home/share/cpputest/cpputest-latest/cpputest_build' に入ります
g++ -DHAVE_CONFIG_H -I. -I.. -include ../include/CppUTest/MemoryLeakDetectorMallocMacros.h -I ../include -nostdinc++ -Wno-missing-exception-spec -include ../include/CppUTest/MemoryLeakDetectorNewMacros.h -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-c++14-compat -Wno-c++11-long-long -Wno-long-long -Wall -Wextra -Wshadow -Wswitch-default -Wswitch-enum -Wconversion -pedantic -Wsign-conversion -Woverloaded-virtual -Wno-disabled-macro-expansion -Wno-padded -Wno-reserved-id-macro -Wno-keyword-macro -Wno-global-constructors -Wno-exit-time-destructors -Wno-weak-vtables -Wno-old-style-cast -g -O2 -MT src/CppUTest/lib_libCppUTest_a-CommandLineArguments.o -MD -MP -MF src/CppUTest/.deps/lib_libCppUTest_a-CommandLineArguments.Tpo -c -o src/CppUTest/lib_libCppUTest_a-CommandLineArguments.o `test -f 'src/CppUTest/CommandLineArguments.cpp' || echo '../'`src/CppUTest/CommandLineArguments.cpp
（～中略～）
ar cru lib/libCppUTestExt.a src/CppUTestExt/lib_libCppUTestExt_a-CodeMemoryReportFormatter.o src/CppUTestExt/lib_libCppUTestExt_a-GTest.o src/CppUTestExt/lib_libCppUTestExt_a-IEEE754ExceptionsPlugin.o src/CppUTestExt/lib_libCppUTestExt_a-MemoryReportAllocator.o src/CppUTestExt/lib_libCppUTestExt_a-MemoryReporterPlugin.o src/CppUTestExt/lib_libCppUTestExt_a-MemoryReportFormatter.o src/CppUTestExt/lib_libCppUTestExt_a-MockActualCall.o src/CppUTestExt/lib_libCppUTestExt_a-MockExpectedCall.o src/CppUTestExt/lib_libCppUTestExt_a-MockExpectedCallsList.o src/CppUTestExt/lib_libCppUTestExt_a-MockFailure.o src/CppUTestExt/lib_libCppUTestExt_a-MockNamedValue.o src/CppUTestExt/lib_libCppUTestExt_a-MockSupport.o src/CppUTestExt/lib_libCppUTestExt_a-MockSupportPlugin.o src/CppUTestExt/lib_libCppUTestExt_a-MockSupport_c.o src/CppUTestExt/lib_libCppUTestExt_a-OrderedTest.o
C:\msys64\mingw64\bin\ar.exe: `u' modifier ignored since `D' is the default (see `U')
ranlib lib/libCppUTestExt.a
make[1]: ディレクトリ '/c/home/share/cpputest/cpputest-latest/cpputest_build' から出ます
pacman で並行して CppUTest をインストールしてしまったので今回はビルド までで終了です。
ちなみにしばらく私はビルドしたこの本家のCppUTestを使うときには、自分 のプロジェクトごとに環境用のシェルスクリプトを作成して毎回 source して 使うようにしようと思っています。面倒っちゃ面倒ですが、どこまで CppUTest を使うか自分でもわからないのでしばらくはこういった運用をして いこうと思います。
※CppUTest を使うときには、環境変数 CPPUTEST_HOME を設定し、パスを通し て使います。使うたびに以下のようなシェルスクリプトを（一度）sourceして 使う、ということになります。
export CPPUTEST_HOME="c:/home/share/cpputest/cpputest-latest"
export PATH=$PATH:${CPPUTEST_HOME}
Google test を導入してみる
Table of Contents
Google test を導入してみる :GTEST:
普段、マイコンを使った組み込みシステムの開発業務をしている中で、 テスト駆動開発の必要性を感じることがあり、ちょっとずつでも単体テスト手 法を学んでいこうかなぁ、というモチベーションがありまして。今回はGoogle Test を導入してまずは環境を整えてみることにします。
Google test のインストール（MSYS2環境）
参考： https://manabisystem.com/how-to-install-google-test-on-msys2/
諸々の事情から Windows 環境がメインなのでMSYS2環境に導入します。上記 によると本家のGit Hub上にあるソースコードではうまくいかないらしいので、 pacman を使って導入するのが吉らしいです。
$ pacman -S mingw-w64-x86_64-gtest
何の問題もなくインストールできました（バージョンは、 mingw64/mingw-w64-x86_64-gtest 1.11.0-5 でした）。
Google test の動作確認
インストールした Google Test を早速ためしてみます。インターネット上 を探せば例はいくつもでてきますが、勉強中の手持ちの本で、「モダンC言語 プログラミング, 花井志王,ASCII DWANGO」、があるのでこの中での例を試して みます。
※参考書の中では eclipse を使って Google Test を動かしていますが、簡単 な例ならコマンドラインからでも十分なのでコマンドラインで g++ を使いま す。
準備するのは4つのコードです。
・ add_test.cc ・・・ テストコード。
・ add.c, add.h ・・・ 検証対象の関数（add）。
・ main.c ・・・ main 関数。
[add_test.cc]
#include "gtest/gtest.h"
#include "add.h"
TEST(AddTest, onePlusTwoGivesThree) {
EXPECT_EQ(3, add(1, 2));
}
[add.h]
#ifndef ADD_H_
#define ADD_H_
#ifdef __cplusplus
extern "C" {
#endif
int add(int i1, int i2);
#ifdef __cplusplus
}
#endif
#endif
[add.c]
#include "add.h"
int add(int i1, int i2) {
//return 0; ← Fail を出したいときのコード
return i1 + i2;
}
[main.c]
#include "gtest/gtest.h"
int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
この4つのコードを、コマンドラインからg++ を使ってコンパイルすると test.exe ができ、テストが実行できます。なお、コンパイル時には gtest と pthread をライブラリとして使用しています（参考書に書いてある通りです）。
g++ add_test.cc add.c main.c -Lc:/msys64/mingw64/lib -lgtest -lpthread -o test
結果は次の通りとなり、テストに成功しました。
# # ./test.exe
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from AddTest
[ RUN ] AddTest.onPlusTwoGivesThree
[ OK ] AddTest.onPlusTwoGivesThree (0 ms)
[----------] 1 test from AddTest (0 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[ PASSED ] 1 test.
これで Google Test できる環境が動作することが確認できました。今後少しず つ学習を進めていきたいと思います。
書き散らかし：[2022-05-14 土]
Table of Contents
-
- magit 導入できない問題：解決:EMACS:MSYS2:
- Windows で使う文字コードを検討：メモ:ENVIRONMENT:
- magit で文字化け：解決:EMACS:GIT:
- emacs 文字コード設定（init.el）:EMACS:
magit 導入できない問題：解決 :EMACS:MSYS2:
先日までインストールできなかったのですが、結局、gnupg を導入してあげ ると EMSCS でパッケージインストールすることができました。
※M-x package-list-packages を実行（M-x package-refresh-contents を忘れずに）
Windows で使う文字コードを検討：メモ :ENVIRONMENT:
- 将来的には、UNICODE になっていく → 流れは、 Unicode UTF-8 BOMなしの方向らしいです。
- 20219年にメモ帳の文字コードが、UTF-8 CR/LF がデフォルト設定になった
- 改行コードを LF にするか、 CR/LF にするか悩む・・・。
magit で文字化け：解決 :EMACS:GIT:
Magit は導入できたのですが、ステータス表示で文字化けしてしまったので 解析します。
最初に、Emacs の .init.elでの文字コード設定を整理し、調査を進めます。
MSYS の文字コードは utf-8 なので init.el の以下の設定が問題になって いるかもしれない。
(setq default-process-coding-system '(undecided-dos . utf-8-unix))→ init.el をコメントアウトしてもmagit の表示はかわらなかった。
→ ちなみにコメントアウトした状態での値（default-process-coding-system）は (japanese-shift-jis-dos . japanese-shift-jis-unix) となっています。
→ 次のように設定してもだめ。
(setq default-process-coding-system '(utf-8-unix . utf-8-unix))magit 表示の文字コード
Emacs の magit バッファ上で次のように SJIS になっています。
Default coding system (for new files): S -- japanese-shift-jis (alias: shift_jis sjis)→ 新しいバッファを開くときの coding system を utf-8 にすればよいのではないだろうか？
新しいバッファを開くときのコーディングシステムが選択できないか調査する
参考： http://blog.livedoor.jp/tek_nishi/archives/8698333.html
これは参考になるが、新しいファイルの場合なので非該当。
(set-coding-system-priority 'utf-8) 参考： https://kfujieda.hatenablog.com/entry/20130905/1378361586
これが有力と思われたが、残念ながら改善されなかった。ただし、 "（コミット時に）UTF8なのにshift_jisと判定されて文字化けする"、 と書いてあるところがある。これは参考になるかもしれない。
→ set-coding-system-priority を utf-8 にしているのに describe-coding-system では sjis のままだった。なぜか？
msys2 のコンソールで echo コマンドを使ってリダイレクトすると、utf-8 で出力されている。
- msys2 のコンソールで git log コマンドを使うと文字化けする。
msys2 のコンソールで git log コマンドをリダイレクトしてファイル に落とし、ファイルを開くと sjis に近い文字で保存されているのがわ かる。文字化けの様子↓。
ﾂコﾂミﾂッﾂトﾂつｵﾂてみて禿ｺﾂ本ﾂ語がﾂ可ｻﾂつｯﾂるこﾂとづｰﾂ確ﾂ認ﾂつｷﾂづｩﾂ。git の文字コード設定がどうなっているのか調べる
init.el で coding-system を sjis に戻すようなところがないか確認する。
→ init.el内で、 (set-language-environment "Japanese") が (set-default-coding-systems 'utf-8) の後になっててこれが set-default-coding-systems を SJIS に戻していたこといたことが原因 と思われる。
つまり、set-language-environment "Japanese" にすると、暗黙的にsjis が選択されるということだろう。
(set-language-environment "Japanese") は、(prefer-coding-system 'utf-8) で代替できるはずなので、(set-language-environment "Japanese") をコメントアウトして問題がないか確認する。
→ 特に問題なかった
magit のコミットバッファは、 undicided-Unx だったが、 default-coding-systems が utf-8 ならコミット結果の文字化けが消えた。
【結論】
- magit のコミットログが文字化けしていたのは、utf-8 で構築していた msys2, emacs 環境で default-coding-systems が sjis になっていたから。
- これは, (prefer-coding-system 'utf-8) の後に (set-language-environment "Japanese") を init.el に書いていたから。
emacs 文字コード設定（init.el） :EMACS:
Reference
- 文字コード設定例
http://yohshiy.blog.fc2.com/blog-entry-273.html
- emacs マニュアル
https://ayatakesi.github.io/lispref/25.3/html/Default-Coding-Systems.html
キーワード調査
set-language-environment 言語環境の設定。これは Windows では SJIS（cp932）なのでこの指定を最初に行う。 UFT-8の設定はこの後に行うこと。
prefer-coding-system (prefer-coding-system 'utf-8)
- デフォルトの文字コードを設定するもの。
- こちらは改行コードとのセットのシンボルにも使える。
set-file-name-coding-system (set-file-name-coding-system 'cp932) → (set-file-name-coding-system 'utf-8)
locale-coding-system なし
default-process-coding-system
(setq default-process-coding-system '(undecided-dos . utf-8-unix))set-buffer-process-coding-system (add-hook 'shell-mode-hook (lambda () (set-buffer-process-coding-system 'utf-8-unix 'utf-8-unix) ))
set-keyboard-coding-system (set-keyboard-coding-system 'utf-8)
coding-system-put ;; UTF-8エンコードの表記変更 (coding-system-put 'utf-8 :mnemonic ?U) (coding-system-put 'utf-8-with-signature :mnemonic ?u)
eol-mnemonic-**
;; 改行コードの表記追加 (setq eol-mnemonic-dos ":Dos ") (setq eol-mnemonic-mac ":Mac ") (setq eol-mnemonic-unix ":Unx ") (setq eol-mnemonic-undecided ":??? ")set-default-coding-systemsデフォルトの文字コードを設定するもの。改行 コードとセットで使える prefer-coding-system の方がベターらしい。
set-terminal-coding-system
set-buffer-file-coding-system (set-file-coding-systemでもよい（エイリアス）) バッファの coding-system を変更する関数。
なお、ここで設定した値は変数 buffer-file-coding-system に保存される。 M-x help
v buffer-file-coding-system でヘルプと供に値を確認できる。 編集バッファの内容がファイルに書き出される時は、この変数に指定された文字コードで書き出される。 M-x describe-coding-system でも確認は可能。 set-coding-system-priority 文字コード自動判定の優先順位を決める。describe-coding-system の最後の方に優先順位が記載される。
process-coding-system-alist
ex
(add-to-list 'process-coding-system-alist '("git" utf-8 . utf-8)) (add-hook 'git-commit-mode-hook '(lambda () (set-buffer-file-coding-system 'utf-8)))
-
- LANG : ja_JP.UTF-8
書き散らかし：[2022-05-12 木]
Table of Contents
-
- magit 導入できない問題3 lispの直接コピー:EMACS:MSYS2:
magit 導入できない問題3 lispの直接コピー :EMACS:MSYS2:
先日は melpa でのインストールに失敗したということで。
GitHub より直接古いリリースの Zip を持ってきてパスを通して動くかどうか見みてみます。 magit-2.90.1 を試す。適当なところにおいてパスを通す。
(setq load-path
(append '("~/.emacs.d/magit_tmp/") load-path))
(require 'magit)
同じことを考える人がいて、
https://nofu.jp/wiki/emacs/emacs26.1_use_magit_on_windows_10
が参考になりました。
やってみると dash がない、と言われるのでインストールします。
dashはうまくいったが、次は with-editor がない、と言われてしまいました。 これも compat-28.1.1.0 に依存してるため、melpa では incompat になる。
そもそも compat-28.1.1.0 を導入すればよいのではないか、とも思う。 これは MELPA にはなく、ELPA には入っている模様。GitHub のサイト。
書き散らかし：[2022-05-16 月]
Table of Contents
メモ
- org-publish の html テーマについて散策
org-mode の見出しのインデントをつけるようにする：解決 :EMACS:
次のように設定する。
(setq org-startup-indented t)
こうすると org バッファ上では見出し毎にインデントがついて見えます （元のテキストファイルにはインデントはついてない）。
長文を書く時には結構よいですね。
書き散らかし：[2022-05-11 水]
Table of Contents
-
- magit 導入できない問題：未解決:EMACS:MSYS2:
- Magit 導入できない問題2：未解決:EMACS:MSYS2:
- easy guntt の導入：解決:REDMINE:
本日の技術メモ。
magit 導入できない問題：未解決 :EMACS:MSYS2:
参考: https://www.arat.xyz/wordpress/?p=179
上記に、
"MELPAに登録されているパッケージの中には更新頻度が高いものもあり、時々 アップグレードによって不具合が生じる場合もあります"
と書いてありました。依存関係によってMELPAに登録されていない依存パッケー ジがあると問題になるらしいです。ちょっと試してみたけどだめだった。
※ gnupg を導入すれば導入できるのですが、それは後日わかったことで・・・。
Magit 導入できない問題2：未解決 :EMACS:MSYS2:
magit の GitHub の Magit User Manual にインストール方法が書いてある。 参考にはなるが、今回の件の解決にはならないと思う。
easy guntt の導入：解決 :REDMINE:
別記事である、"easy guntt の導入"、に移動。
