Linuxのデスクトップとサーバーについて扱います。Plugin、できてます。この前の新Mac騒動でCtrl+]を初めて知った@MNukazawaです。相変わらずESCを連打しています。投稿してから文字サイズがおかしいことに気づいたのですが、ざっくり対処しておきますので、多少おかしくても勘弁いただければと思います。まえがき家でも仕事でも、C言語を書くときは(C言語を書くときに限らず)Vimを使っています。ライトVimmerにとって、Vimは最高ですが、完璧ではないです。C言語での開発とVimとの相性は最高ですが、光のあるところには影もあり、以下に書いてあるアレコレのつらみに、私は今も苦しんでいます。今回挙げた中には、受け入れていかなければならないものや、いかにも井の中の蛙っぽい悩みも含まれており、解決策やベストプラクティスが無いはずがないと思えるものもあります。「プラグイン忌避を克服しろ」「Vimの基本コマンドくらい覚えろ」等々、厳しくツッコミを入れて頂けると、正直とても嬉しいです。私は現在、Vecterion(べくてりおん)という名前のベクターグラフィック・エディタを書いています。今回のVim記事も、VecterionをVimで書いているときの話をするので、Vecterionのスペックをざっくり挙げておきます。C言語/GTK3で書いている。中規模アプリケーション(1人で開発。アプリケーション本体のヘッダとソースが50個ずつ有る)リリースはまだしていませんが、昨日もリリースブロッカを一つ潰したので、来年のどこかでは...。」でざっくり書いたので、よければどうぞ。中規模アプリケーションは、ヘッダとソースが別パスになる。%<.h`が効かなくなるため、移動が面倒。仕方なしにヘッダからソースへの移動は、目に付いた適当な関数を叩いて飛んでいる。いうか、ソースへのアクセスもとりあえずヘッダを開いてctagsでソースへ飛び、いつでもctagsのスタックでヘッダへ飛べるようにしておく、という運用をしている。Vimに必須なctagsが絡むと、ディレクトリが深くなりタイプ量が増えるctagsは、tagsファイル生成と利用のために、vimのカレントディレクトリを、常にプロジェクトのソース先頭にしておかないと都合が悪い。なくても、ソースとヘッダの間を行き来することを考えると、Tab補完はあるものの、ディレクトリの分だけタイプ数が増えることを受け入れなければならない。今どきな長めの名前で、インテリセンス無しで書く今どきの関数・変数名は、省略を避けるなど、なんとなく長い名前になりがち。長い名前をインテリセンス無しで書くのはつらい。(名前が長いこと自体は、自分が悪い気がしないでもないが。)Vimは最高のテキストエディタだが、最高のIDEであるとは限らない。p1_handle_prev_dst);`インテリセンスのプラグインに決定打がない。ついでにVimプラグインはインストールがつらい。「リファクタリング」というほど格好良くなくても、開発していて名前を変えたくなることは多い。Vimのリネームは1ファイル内のみプロジェクト内でファイルを跨いだ命名変更がしたいとき、Vimは無力。ヘッダ・ソース合わせて100ファイルを超えているので手作業は嫌。*/*.[hc]`を使っている。sedでリネームしやすい名前を付けている(付けなければならない)つまり`sed`しやすい名前を付けなければならない。"layer_element"などと名付ける。リネームしずらいので、"elem"とか"e"とは付けない。(というか初期に一部のコードでそういった変数名を付けてしまったので、後で直さないと...)関数の引数を変更したいとき、引数に折り返しがあるとsedできなくてつらい。(これはIDEでも難しいだろうけれど)ファイルの"path"(filepath)と被るのが怖くて、アンカーポイントで構成される線分"path"(ahchorpath)と名づけるのを避けて、変な名前を付けたりしていた。ctagsでstatic関数定義へ飛ぶとき中規模以上のC言語プロジェクトでは、ファイルローカルなstatic関数を定義する。コーディングルールによったり、その他の都合で、ソースの先頭近くでファイルローカルstatic関数の定義をすることになる。Vimを使うならば、ctagsで関数間をジャンプする。ctagsは最初の候補としてstatic関数の宣言へ飛ぶが、私は定義を見たいいつもCtrl+]とCtrl+Tを使っている。Vimのタグジャンプ自体はとても便利で多用するので、いつも常に:tsと打って候補一覧を見てから数字キーで飛び先を指定する、なんてことはしたくない。-R`するのがつらい。コミット前のコードは、書きかけの関数が消えたり、名前が変わったりが頻繁に起こる。-R`を何度か打つことになる。ディレクトリに複数のソースファイルを抱えたプロジェクトで、再帰的にソースを探索させるとctagsも2~3秒かかることもある。Vimはデフォルトでインデント整形できる機能が用意されているのがすばらしいしかし完璧ではないので、以下のような考慮すべき点がある。case{}とLinuxコーディング規約の衝突Linuxコーディング規約よりインデントが1段深い。8tabを使っていると8文字分の横幅を使われる。他の開発者に触ってもらうなどを考えると、Vimのデフォルトから.vimrcで変えたくなかった。一人で開発しているだけなら、そのうち慣れたので大きな問題でもない。C{}がVimの自動インデントで引っかかる。ヘッダ全体にインデントが一段かかってしまう。googletestでテストを書こうとするとこれに悩む。C{}することで解決。CヘッダがC++に考慮するのが間違いと思うことにする。C++テストコード内のinclude行だけの問題になる。-」みたいな記事を書いたほうが良い気がしています。それよりVimコマンドを覚えたほうが有意義そうですが。水の中の魚は水のことを意識することがありません。Vimを使ってC言語でコードを書いていると、ctagsの有り難みをつい忘れてしまいがちです(Windows上のAtomでソースを開いたときに思い出す)。それは必ずしも悪いことではないのだと思います。快適なVimコーディングも、使い続けていると細かいところでつらみが意識されるようになるのも、自然なことで、だからこそ先達たちは多用なVimプラグインを生み出してきたのかもしれません。16日目の記事でした。シューズを買いました。メインの靴がアシックスウォーキングで街歩き用なのですが、これまではこれで高尾山などの軽い山も登っていました。今回、靴底があまりに摩耗したこともあってアシックスウォーキングを買い替えたのですが、ついでに消耗が激...100均の液晶保護フィルムを13インチのノートPCに貼ってみましたノートPCの液晶保護フィルムが100円で買えるなんて、良い時代になりました。ダイソーに行ったら、ノートPCで使えそうな液晶保護フィルムがあったため、衝動的に購入。A4サイズと書いてあります。(HTMLでPOST、そしてhidden)formでユーザの入力やファイルを送信する際、IDを付与したり、送信した情報を紐付けるか、などの情報を一緒に送信したい場合があります。その場合、ID情報はブラウザに表示しないのがベストです。ユーザに見せたり、編集してもらう必要はありません。オルタネイティヴは数あれど、小さな実験プロジェクトを始めるときに、簡単に使えるMakeは未だにビルドツールとして有力な選択肢だと思います。MakefileはUNIX環境、というかCLIツール群があることを前提にしているところがあります。