my_help 0.4.3 → 0.4.4

data/my_help_nasu/code.hiki

@@ -0,0 +1,285 @@
+{{toc}}
+!結果
+
+CucumberとRSpecを用いてBDDでmy_helpのテスト開発を進めて行きました．
+// アプリの振る舞いを説明する
+// なぜ自分が作ったかを納得してもらえないから．
+// 自分の作業の目的の意義を説明するために，全体の概要を説明することは妥当
+// 先行研究->先行開発，ソフト開発==研究，why!!
+ここでは，焦点を合わせたmy_helpの中での一つの振る舞いである
+「todoの更新」を例として詳しく見て行きます．
+
+!!todoの更新マニュアル
+最初に，todoを更新するときの手順を示します．
+
+#my_todo --editを入力して~/.my_help/my_todo.ymlを開く
+#editorでtodoを書き込む（今週やることならweeklyというitemを作ってそこに書き込む）
+#保存して~/.my_help/my_todo.ymlを閉じる
+#my_todoと打ち込んで更新されていたら完成
+#my_todo --store [item]を入力してitemのバックアップをとる
+
+この振る舞いがきちんとできているのかを実際にテスト構築して行きます．
+
+!!Cucumber
+
+以下はtodoの更新を行うときのfeatureです．
+まず，適当なディレクトリにfeaturesというディレクトリを作成します．
+次に先ほど作成した，featuresディレクトリにmy_todo.featureを作成します．
+<<< tcsh
+# language: ja 
+
+機能: todoの更新を行う
+todoは更新していくものであり,新しく書いたり終わったものを
+消したいのでバックアップをとって，過去のtodoを残しておく
+
+
+ シナリオ: コマンドを入力してtodoを更新していく
+          前提 todoを編集したい
+          もし "my_todo --edit"と入力する
+          ならば editが開かれる
+          かつ 自分のtodoを書き込む
+
+シナリオ: コマンドを入力してバックアップをとる
+          前提 todoの編集が終わった
+          もし "my_todo --store [item]"と入力する
+          ならば itemのバックアップを取る
+
+>>>
+
+機能とは，このシステムの機能のことを記述します．ここでは，todoを更新するシステムですので，「todoの更新を行う」です．
+機能の下には，機能の補足説明を記述します．機能の補足説明では，ルールがないので自分がわかりやすいように，記述するのが常識です．
+シナリオは，その名の通りtodoを更新する時のユーザの行動やシステム振る舞いを前提，もし，ならば，かつ，しかしに分類して記述します．
+シナリオは，一つの機能に対して複数書くことが可能です．ここでは、「todoを更新する」と「バックアップをとる」という二つの
+シナリオをたてています．
+
+ここまでfeatureが記述できたら，次はcucumberコマンドを実行してみます．
+コマンドは以下の通りです．
+　/Users/nasubi/nasu% cucumber features/my_todo.feature 
+featuresディレクトリにあるmy_todo.featureファイルをcucumberで実行するという意味です．
+
+実行すると以下のようになります．
+
+<<< tcsh
+# language: ja
+機能: todoの更新を行う
+todoは更新していくものであり,新しく書いたり終わったものを消したいのでバックアップをとって，過去のtodoを残しておく
+
+  シナリオ: コマンドを入力してtodoを更新していく # features/my_todo.feature:6
+    前提todoを編集したい             # features/my_todo.feature:7
+    もし"my_todo --edit"と入力する  # features/my_todo.feature:8
+    ならばeditが開かれる             # features/my_todo.feature:9
+    かつ自分のtodoを書き込む           # features/my_todo.feature:10
+
+  シナリオ: コマンドを入力してバックアップをとる          # features/my_todo.feature:12
+    前提todoの編集が終わった                  # features/my_todo.feature:13
+    もし"my_todo --store [item]"と入力する # features/my_todo.feature:14
+    ならばitemのバックアップを取る               # features/my_todo.feature:15
+
+2 scenarios (2 undefined)
+7 steps (7 undefined)
+0m0.080s
+
+You can implement step definitions for undefined steps with these snippets:
+
+前提(/^todoを編集したい$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+もし(/^"([^"]*)"と入力する$/) do |arg1|
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+ならば(/^editが開かれる$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+ならば(/^自分のtodoを書き込む$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+前提(/^todoの編集が終わった$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+ならば(/^itemのバックアップを取る$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+>>>
+
+ここでは，2つのscenarioと7つのstepが失敗しています．
+まだstep定義を記述していないので当たり前です．
+
+一度cucumberを実行したのには理由があります．
+featureを書いた時点でcucumberを実行すると，ステップ定義の元となるコマンドを，cucumberが自動的に作成してくれるからです．
+
+以下がcucumberから出力されたステップ定義の元となる部分です．
+<<< tcsh
+You can implement step definitions for undefined steps with these snippets:
+
+前提(/^todoを編集したい$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+もし(/^"([^"]*)"と入力する$/) do |arg1|
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+ならば(/^editが開かれる$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+ならば(/^自分のtodoを書き込む$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+前提(/^todoの編集が終わった$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+
+ならば(/^itemのバックアップを取る$/) do
+  pending # Write code here that turns the phrase above into concrete actions
+end
+>>>
+
+これをコピーして，featuresディレクトリの中でstep_definitionsディレクトリを作成し，その中にmy_todo_spec.rbを作成し，そこに貼付けます．
+
+ここでもう一度cucumberを実行してみると
+<<< tcsh
+/Users/nasubi/nasu% cucumber features/my_todo.feature 
+# language: ja
+機能: todoの更新を行う
+todoは更新していくものであり,新しく書いたり終わったものを消したいのでバックアップをとって，過去のtodoを残しておく
+
+  シナリオ: コマンドを入力してtodoを更新していく # features/my_todo.feature:6
+    前提todoを編集したい             # features/step_definitions/my_todo_spec.rb:1
+      TODO (Cucumber::Pending)
+      ./features/step_definitions/my_todo_spec.rb:2:in `/^todoを編集したい$/'
+      features/my_todo.feature:7:in `前提todoを編集したい'
+    もし"my_todo --edit"と入力する  # features/step_definitions/my_todo_spec.rb:5
+    ならばeditが開かれる             # features/step_definitions/my_todo_spec.rb:9
+    かつ自分のtodoを書き込む           # features/step_definitions/my_todo_spec.rb:13
+
+  シナリオ: コマンドを入力してバックアップをとる          # features/my_todo.feature:12
+    前提todoの編集が終わった                  # features/step_definitions/my_todo_spec.rb:17
+      TODO (Cucumber::Pending)
+      ./features/step_definitions/my_todo_spec.rb:18:in `/^todoの編集が終わった$/'
+      features/my_todo.feature:13:in `前提todoの編集が終わった'
+    もし"my_todo --store [item]"と入力する # features/step_definitions/my_todo_spec.rb:5
+    ならばitemのバックアップを取る               # features/step_definitions/my_todo_spec.rb:21
+
+2 scenarios (2 pending)
+7 steps (5 skipped, 2 pending)
+0m0.045s
+
+>>>
+と変化が出てきます．
+ 2 scenarios (2 pending)
+ 7 steps (5 skipped, 2 pending)
+これは2つのシナリオの内２つがpendingであり，７つのstepの内２つがpendingで５つがskipしたことを表しています．
+step_definitionsのmy_todo_spec.rbのpending部分を書き換えて，step_definitionsの記述を進めて行きます．
+
+cucumberが成功すると下記のような結果となります．
+
+<<< ruby
+/Users/nasubi/my_help% cucumber features/my_todo.feature 
+# language: ja
+機能: todoの更新を行う
+todoは更新していくものであり,新しく書いたり終わったものを消したいのでバックアップをとって，過去のtodoを残しておく
+
+  シナリオ: コマンドを入力してtodoを更新していく # features/my_todo.feature:6
+    前提todoを編集したい             # features/step_definitions/my_todo_spec.rb:2
+    もし"my_todo --edit"と入力する  # features/step_definitions/my_todo_spec.rb:6
+    ならばeditが開かれる             # features/step_definitions/my_todo_spec.rb:10
+    かつ自分のtodoを書き込む           # features/step_definitions/my_todo_spec.rb:14
+
+  シナリオ: コマンドを入力してバックアップをとる          # features/my_todo.feature:12
+    前提todoの編集が終わった                  # features/step_definitions/my_todo_spec.rb:18
+    もし"my_todo --store [item]"と入力する # features/step_definitions/my_todo_spec.rb:6
+    ならばitemのバックアップを取る               # features/step_definitions/my_todo_spec.rb:22
+
+2 scenarios (2 passed)
+7 steps (7 passed)
+0m0.030s
+
+>>>
+
+!!RSpec
+次にRSpecを使って実際にtodoを更新する振る舞いをするコード書いていく．
+
+そのための準備として，まずspecというディレクトリを作成し，my_todoというサブディレクトリを追加する．
+次に，このサブディレクトリにtodo_spec.rbというファイルを追加する．
+作業を進める過程で，lib/my_todo/my_todo.rbソースファイルとspec/my_todo/todo_spec.rbスペックファイルが１対１に対応するといった要領で，
+並列のディレクトリ構造を築いていく．
+この機能はmy_help --editと入力されれば，~/.my_help/my_todo.ymlが開かれるのでその振る舞いをするコードを書きます．
+まずtodo_spec.rbは下記の通りになります
+
+<<< ruby
+require 'spec_helper'
+
+
+module Mytodo
+  describe Todo do
+    describe "#open" do
+      it "open file my_todo.yml" 
+    end
+  end
+end
+
+>>>
+
+describe()メソッドは，RSpecのAPIにアクセスしてRSpec::Core::ExampleGroupのサブクラスを返します．
+ExampleGroupクラスはオブジェクトに期待される振る舞いのサンプルを示すグループです．
+it()メソッドはサンプルを作成します．
+
+このスペックを実行するために，specディレクトリにspec_helper.rbを追加します．
+中身は下記の通りです．
+
+<<< ruby
+$LOAD_PATH.unshift File.expand_path('../../lib', __FILE__)
+require 'my_help'
+require 'todo'
+>>>
+
+これで事前準備は完成でコードを書いていきます．
+
+完成したコードを下記の通りです．
+
+<<< ruby
+require 'spec_helper'
+
+
+module Mytodo
+  describe Todo do
+    describe "#open" do
+      it "open file my_todo.yml" do
+          system("emacs ~/.my_help/my_todo.yml")
+      end
+    end
+  end
+end
+
+>>>
+
+これでrspecを実行すると以下のような結果が表示される．
+<<< tcsh
+/Users/nasubi/my_help% rspec spec --color
+
+my_help command
+  version option
+    should be successfully executed
+    should have output: "my_help 0.4.3"
+  help option
+    should be successfully executed
+    should have output: "Usage: my_help [options]\n    -v, --version                    show program Version.\n    -l, --list...              install local after edit helps\n        --delete NAME                delete NAME help"
+
+Mytodo::Todo
+  #open
+    open file my_todo.yml
+
+Finished in 3.87 seconds (files took 0.30703 seconds to load)
+5 examples, 0 failures
+
+>>>
+これでtodoを更新するときの振る舞いのテストはうまく成功した．
+
+この方法でBDDでmy_helpのテスト開発を行い，仕様を決定していった．

data/my_help_nasu/consideration.hiki

@@ -0,0 +1,8 @@
+!考察
+　今回の開発において，ユーザメモソフトであるmy_helpのテスト開発は成功した．
+つまり，my_helpの仕様と動作の標準が確定したことで，今後のソフトを進化させるための共同開発がスムーズにいくと推測される．
+先に述べた通り，ソフト開発は一人でせず，複数人で開発することが普通である．
+その時に起こる障害として，意思の疎通ができていないことがあげられる．
+振る舞いが標準化されていないと，どのような振る舞いをするのかが，プログラムを見るだけでは，ずれが生じてしまう．
+また，開発者の意図が読めていないと，コードの意味も変わってくるので，テスト開発をして，仕様と動作の標準を確定することは重要であった．
+加えて，初めてmy_helpを使うユーザでも仕様と動作の標準がわかっていれば，短い時間でmy_helpを使いこなせるし，そのことによって，ユーザそれぞれに自分にあったmy_helpに変更することも容易になる．

data/my_help_nasu/features.hiki

@@ -0,0 +1,185 @@
+{{toc}}
+!!featuresでの記述とその意味
+featuresでの記述は，コマンドの振る舞いを説明する自然な記述となる．
+その様子をspecific_helpが用意しているデフォルトのコマンドについて
+説明する．specific_helpとは，ユーザが作成するそれぞれのヘルプである．
+speific_helpの--helpを表示させると，
+<<< 
+        --edit                       edit help contentsを開く
+        --to_hiki                    hikiのformatに変更する
+        --all                        すべてのhelp画面を表示させる
+        --store [item]               store [item] でback upをとる
+        --remove [item]              remove [item] back upしてるlistを消去する
+        --add [item]                 add new [item]で新しいhelpを作る
+        --backup_list [val]          back upしているlistを表示させる
+>>>
+が得られる．これらの項目について順に詳細な振る舞いとそれを記述する
+シナリオを検討していく．
+
+
+!!my_helpのfeatures
+下記は私が作成したmy_helpの一部をfeaturesで書いたものである．
+
+!!!--add [item]
+このコマンドは新しいitemをspecific_helpに追加する．
+提供される機能を
+シナリオの先頭に内容をかいつまんでこの振る舞いが記述されている．
+実装では，ヘルプの内容は~/.my_help/emacs_help.ymlに元dataがある
+
+<<< 
+nasu% cat add.feature
+#language: ja
+
+#--add [item]
+機能: 新しいitemをspecific_helpに追加する
+specific_helpとは，ユーザが作成するそれぞれのヘルプである
+新しいhelp画面を追加したい
+
+シナリオ: コマンドを入力してspecific_helpにitemを追加する
+        前提 新たなhelpコマンドを追加したい
+        もし emacs_help --add[item]を入力する
+        ならば ~/.my_help/emacs_help.ymlに新しいitemが自動的に追加される
+
+>>>
+
+
+!!!全てのhelp画面の表示
+<<< all_help.feature
+
+#language: ja
+
+#--all
+機能: 全てのhelp画面を見る
+複数のhelp画面を一度に見たい時に便利である
+
+シナリオ: コマンドを入力してすべてのhelpを見る
+        前提 複数のhelp画面を表示したい
+        もし emacs_help --allと入力する
+        ならば すべてのhelp画面が表示される
+>>>
+シナリオ：コマンドをニュ力してすべてのhelp画面を見る
+
+コマンド：emacs_help --all
+
+!!!過去にバックアップしてあるitemのリストの表示
+<<< backup_list.feature
+#language: ja
+
+#--backup_list
+機能: 過去にバックアップしてあるitemのリストを表示させる
+何をバックアップしたかの確認をしたい
+
+シナリオ: コマンドを入力してバックアップのリストを見る
+        前提 バックアップのリストを見たい
+        もし emacs_help --backup_listを入力する
+        ならば バックアップしているitemのリストが表示される
+        
+>>>
+シナリオ：コマンドを入力してバックアップのリストを見る
+コマンド：emacs_help --backup_list
+
+!!!helpコマンドの追加や削除，編集をするファイルの開示
+<<< edit_help.feature
+# language: ja
+#--edit
+機能: helpコマンドの追加や削除，編集をするためのeiditを開く
+emacs_helpと入力したときに出てくるhelpのコマンドの追加や削除，編集ができる
+
+シナリオ: コマンドを入力してeditを開く
+        前提 emacs_helpのコマンドの編集がしたい
+        もし emacs_help --editと入力する
+        ならば ~/.my_help/emacs_help.ymlがemacsで開かれる
+>>>
+シナリオ：コマンドを入力してeditを開く
+コマンド：emacs_help --edit
+
+元dataである~/.my_help/emacs_help.ymlを開く．
+
+ここで編集を行い，emacsで開いているのでC-x,C-sで保存する．
+
+!!!specific_helpのitemの消去
+<<< remove.feature
+#language: ja
+
+#--remove [item]
+機能: specific_helpのitemを消す
+いらなくなったitemを消したいときに使う
+
+シナリオ: コマンドを入力してitemを消す
+        前提 いらないitemを消したい
+        もし emacs_help remove [item]
+        ならば ~/.my_help/emacs_help.ymlからitemが消える
+
+>>>
+シナリオ：コマンドを入力してitemを消す
+
+コマンド：emacs_help --remove
+
+!!!itemのバックアップ
+<<< store.feature
+#language: ja
+
+#--store [item]
+機能: itemのバックアップを取る
+バックアップとして残したいitemがあるときに使う
+
+シナリオ: コマンドを入力してitemのバックアップをとる
+        前提 バックアップをとっておきたい
+        もし emacs_help --store [item]と入力する
+        ならば 入力したitemのバックアップが作られる
+>>>
+
+シナリオ：コマンドを入力してバックアップをとる
+
+コマンド：emacs_help --store [item]
+
+!!!hikiへのformatの変更
+<<< to_hiki.feature
+# language: ja
+
+#--to_hiki
+機能:formatをhikiモードに変更する
+一つ一つエディタで開いて変更するのがめんどくさい時に有益である
+
+シナリオ: コマンドを入力してformatをhikiモードに変える
+        前提 hikiモードに変更したい
+        もし emacs_help --to_hikiと入力する
+        ならば formatがhikiモードに変更される
+>>>
+シナリオ：コマンドを入力してformatをhikiモードにする
+
+コマンド：emacs_help --to_hiki
+
+!!!todoの更新
+<<< my_todo.feature
+# language: ja
+
+機能: todoの更新を行う
+todoは更新していくものであり,新しく書いたり終わったものを消したいのでバック\
+アップをとって，過去のtodoを残しておく
+
+シナリオ: コマンドを入力してtodoを更新していく
+          前提 todoを編集したい
+          もし "my_todo --edit"と入力する
+          ならば editが開かれる
+          かつ 自分のtodoを書き込む
+
+シナリオ: コマンドを入力してバックアップをとる
+          前提 todoの編集が終わった
+          もし "my_todo --store [item]"と入力する
+          ならば itemのバックアップを取る
+>>>
+シナリオ１：コマンドを入力してtodoを更新する
+シナリオ２：コマンドを入力してバックアップをとる
+
+コマンド１：my_todo --edit
+コマンド２：my_todo --store [item]
+
+my_todo --editで~/.my_help/my_todo.ymlを開く．
+
+ここで編集を行い，emacsで開いているのでC-x,C-sで保存する．
+
+my_todo --store [item]でtodoのitemをバックアップとっておく．
+
+この動作により過去のバックアップを閲覧することができ，どんどん更新することが可能である．
+

data/my_help_nasu/head2.tex

@@ -0,0 +1,9 @@
+\title{卒業論文\\
+\vspace{4cm} ユーザメモソフトmy\_helpの開発}
+\author{ 関西学院大学　理工学部　情報科学科\\\\2535 那須比呂貴}
+\date{\vspace{3cm} 2017年  3月\\
+\vspace{3cm} 指導教員　　西谷　滋人　教授}
+\maketitle
+\setcounter{tocdepth}{4}
+\tableofcontents
+

data/my_help_nasu/hiki_help.yml

@@ -0,0 +1,53 @@
+# -*- coding: utf-8 -*-
+---
+:head:
+- hikiutil関連のヘルプ
+:initialize:
+  :opts:
+    :short: "-i"
+    :long: "--initialize"
+    :desc: hikiで卒論を書くときの初期化と掟
+  :title: hikiで卒論を書くときの初期化と掟
+  :cont:
+  - 開発メモ:figs,dataも作成
+  - 目的：西谷が後で迷わないように決まったファイル構造を堅持すべし
+  - 文書：hikiで書く.のちには，latexに変換するプログラムを提供します
+  - 図表：すべての図表をkeynoteにまとめる，タイトルを分かりやすく書く
+  - データ：dataディレクトリにまとめる．ファイル名をkeynoteの対応する図表中に記す
+  - hiki --initializeで初期ファイル(Rakefile, ./.hikirc, hiki_help.yml)がcopyされる
+  - hiki_help.ymlを適宜~/.my_helpにcopyしてhiki_helpとして利用，(my_help参照)
+  - Errno::EACCESやpermission errorがでたときはrake chenvを試してみる（報告して）
+  - rake syncによってhikiディレクトリーと同期が取られる
+  - hiki -u TARGETによってブラウザー表示される
+  - テキストの拡張子は'.hiki'
+  - hikiでのurlはテキスト前とディレクトリーから自動生成される
+  - 例えば，hiki2latex_saki/introduciton.hikiとするとhiki2latex_saki_introducitonと変換される
+:error:
+  :opts:
+    :short: "-e"
+    :long: "--error"
+    :desc: error対応
+  :title: error対応
+  :cont:
+  - Permission denied - ./data/text/boundary_narita (Errno::EACCES)->テキストにhikiが書き込めない，chmod
+    a+w FILE
+:figs:
+  :opts:
+    :short: "-f"
+    :long: "--figs"
+    :desc: 図表：すべての図表をkeynoteにまとめる，タイトルを分かりやすく書く
+  :title: 図表：すべての図表をkeynoteにまとめる，タイトルを分かりやすく書く
+  :cont:
+  - keynoteに書いたスライドはイメージに書き出して，rake convert 80 TARGET_DIRでfigsに変換
+  - rake syncでfigsにあるfilesはhiki/target_dirにcpされる
+  - 'convert #{source} -resize 20% #{target}によって，target=figs/TAERGET.pngに20%に縮小して保存される'
+  - convert -density 300 view.svg view.pngで300dpiで変換
+  - |
+    attach_anchorでは
+    '{{attach_anchor(test.png, hiki2latex_saki)}}'
+    と，directory指定しなければならない.
+  - keynoteであとで図を挿入して番号が変わった時の原稿の一括変換 
+  - rake increment 2 boundary_bob.hiki boundary_bob > tmp.hiki
+  - rake convert 60 boundary_bob
+  - rake sync
+  - hiki -u boundary_bob_tmp

data/my_help_nasu/introduction.hiki

@@ -0,0 +1,29 @@
+// 目的の前に何が問題があって，何を解決するのかが描かれるべきです．
+!序論
+//!!my_helpというソフト
+プログラム開発では，統合開発環境がいくつも用意されているが，多くの現場では，terminal上での開発が一般的である．
+ところが，プログラミング初心者はterminal上でのcharacter user interface(CUI)を苦手としている．
+プログラミングのレベルが上がるに従って，
+shell commandやfile directory操作, process制御にCUIを使うことが常識となる．
+
+この不可欠なCUIスキルの習得を助けるソフトとして，ユーザメモソフトmy_helpがruby gemsに置かれている．
+このcommand line interface(CLI)で動作するソフトは，helpをterminal上で簡単に提示するものである．
+また，初心者が自ら編集することによって，すぐに参照できるメモとしての機能を提供している．
+これによって，terminal上でちょっとした調べ物ができるため，作業や思考が中断することなく
+プログラム開発に集中できることが期待でき，初心者のスキル習得が加速することが期待できる．
+
+//!!共同開発のためには，テストが必要だが，不十分．
+しかし，Ruby gemsとして提供されているこのソフトは，動作はするがテストが用意されていない．
+慣れた開発者は，テストを見ることで仕様を理解するのが常識である．
+今後ソフトを進化させるために共同開発を進めていくには，仕様や動作の標準となるテスト記述が不可欠となる．
+
+
+//!!BDDに従ってテストを書いていく
+//以下は残しておきますが，適当な時に消してください．
+//本研究の目的は，ユーザメモソフトであるmy_helpのテスト開発です．
+そこで，本研究では，ユーザメモソフトであるmy_helpのテストを開発することを目的とする．
+本研究では、テスト駆動開発の中でも，ソフトの振る舞いを記述する
+Behavior Driven Development(BDD)に基づいてテストを記述していく．
+Rubyにおいて、BDD環境を提供する標準的なフレームワークであるCucumberとRSpecを用いて，
+my_helpがどのような振る舞いをするのかを記述する．
+Cucumberは自然言語で振る舞いを記述することができるため，ユーザにとって，わかりやすく振る舞いを確認することができる．

data/my_help_nasu/key_bind_mi

@@ -0,0 +1 @@
+***control+A:<<<MOVECARET-STARTOFLINE>>>

data/my_help_nasu/latex_dir/.gitignore

@@ -0,0 +1 @@
+.hikirc