dorapon2000’s diary

忘備録的な。セキュリティとかネットワークすきです。

WSL 上にインストールした Rust を VSCode の rust-analyzer 拡張機能に認識させる

WSL 上に Rust をインストール済みで cargo コマンドは認識するのに、VSCode の rust-analyzer には認識できていない。という状況になりました。よくありそうなシチュエーションだと思うんですが、直接的な解決方法の記事が出てこなかったので、まとめます。

前提

  • Windows 11
  • WSL 2.5.9.0
  • VSCode 1.101.1
  • rust-analyzer 0.3.2500
  • rustc 1.87.0
  • cargo 1.87.0

やろうとしたこと

Windows のホームディレクトリ配下で Rust ファイルを作成しており、それを VSCode で開いていました(WSL 管理のフォルダではないという意味です)。Rust は WSL のシェル上にインストールしており、そのシェルを VSCode 内のターミナルで開き、そこから Rust ファイルの実行をしていました。

後半の説明が分かりづらいですが、下図のとおりです。つまり、VSCode 使っている人ならおなじみのシチュエーションということです。

今度は型の情報などを見るべく拡張機能の rust-analyzer を入れました。 自分はてっきりいれるだけで便利な機能が使えると思っていたんですが、うまく動きませんでした。

症状

VSCode のウィンドウの左下に表示されている rust-analyzer の文字が赤く表示されていました。その文字をクリックするとエラーメッセージが表示されています。スクショは取り忘れてしまいました。

2025-06-21T17:23:36.046253+09:00 ERROR failed fetching toolchain version for ManifestPath { file: AbsPathBuf("C:\\Users\\dorap\\Documents\\program\\rust\\lifegame-rs\\Cargo.toml") } workspace e=Failed to query rust toolchain version via "cargo" "--version", is your toolchain setup correctly?
2025-06-21T17:23:36.0479564+09:00 ERROR failed fetching data layout for ManifestPath { file: AbsPathBuf("C:\\Users\\dorap\\Documents\\program\\rust\\lifegame-rs\\Cargo.toml") } workspace e=unable to fetch target-data-layout via "rustc" "-Z" "unstable-options" "--print" "target-spec-json"
2025-06-21T17:23:36.0537314+09:00 ERROR FetchWorkspaceError: rust-analyzer failed to load workspace: Failed to load the project at C:\Users\dorap\Documents\program\rust\lifegame-rs\Cargo.toml: Failed to read Cargo metadata from Cargo.toml file C:\Users\dorap\Documents\program\rust\lifegame-rs\Cargo.toml, None: Failed to run "cargo" "metadata" "--format-version" "1" "--manifest-path" "C:\\Users\\dorap\\Documents\\program\\rust\\lifegame-rs\\Cargo.toml": program not found

イマイチよくわからないエラーだったんですが、ChatGPT 曰く拡張機能が cargo コマンドを見つけられてないみたいでした。

解決方法

まず結論から。WSL から code コマンドで VSCode を開くと解決しました。

# 今回の場合は
cd /mnt/c/Users/dorap/Documents/program/rust/lifegame-rs
code .

ただし、自分の WSL 環境では code コマンドがデフォルトで使えなかったので、設定ファイルを変更しました。/etc/wsl.conf の appendWindowsPath を false から true に変更します。ググった記事にある、コマンドパレットで Shell Command: Install 'code' command in PATH という選択肢が出てこないのがハマりポイントです。

❯ sudo vim /etc/wsl.conf
❯ cat /etc/wsl.conf
[interop]
appendWindowsPath = true

そして、念の為 PC を再起動します。

code コマンドから Rust プロジェクトフォルダを開くと、左下にあった赤文字の rust-analyzer がなくなりますし、rust のファイル内で適当なものにマウスオーバーするとポップアップで説明がされます。

どうやら、リモート接続で開かれているみたいです。

考察

おそらく、Windows に cargo コマンドをインストールしたのではなく、WSL 上にインストールしたから、Windows 上で開いた VSCode は、その cargo コマンドを認識できなかったのだと思います。なので、WSL を別サーバに見立てリモート接続して、それなら cargo が入っている環境だから rust-analyzer ってことかと。

左右を固定幅の要素に挟まれた可変幅の要素の長い文字列を省略したい

この記事は巷であふれている「flex: 1; + text-overflow: ellipsis; の組み合わせが罠だから min-width: 0; をつけよ」という記事になります。 それを知った今検索すると、嫌でも目に付く内容なのですが、実装しているときはまったく気づくことができず沼っていました。 作りたい対象をタイトルにして、自分も記録に残します。

この記事中のソースコードGitHub にあげています。

github.com

実現したい UI

最終的なコード

<!-- index.html -->
<div class="element">
  <div class="left-container">
    <div class="icon"></div>
    <div class="title">とても長いタイトルがここに表示されますとても長いタイトルがここに表示されますとても長いタイトルがここに表示されますとても長いタイトルがここに表示されます</div>
  </div>
  <div class="right-container">
    <button>詳細</button>
    <button>編集</button>
  </div>
</div>
// style.scss
.element {
  display: flex;
  gap: 8px;
  align-items: center;
  justify-content: space-between;
  padding: 8px 12px;
  background-color: #fff;
  border: 1px solid #ddd;
  border-radius: 6px;

  .left-container {
    display: flex;
    flex: 1;
    gap: 8px;
    align-items: center;
    min-width: 0; // <-- 一番伝えたい注意ポイント

    .icon {
      width: 32px;
      height: 32px;
      background-color: #d0e0ff;
    }

    .title {
      flex: 1;
      overflow: hidden;
      text-overflow: ellipsis;
      white-space: nowrap;
    }
  }

  .right-container {
    display: flex;
    gap: 8px;
  }
}

見やすさの関係で css は scss で記載しています。css が必要な方はリポジトリにあります。

解説

長い文字列を省略する

まずは簡単なところから解説します。

      overflow: hidden;
      text-overflow: ellipsis;
      white-space: nowrap;

よくある組み合わせです。nowrap で改行を禁止して、hidden であふれた文字列を隠して、ellipsis で隠れた分を「...」表記させます。

可変と固定

    flex: 1;

Flexbox で唯一その要素の長さだけを可変にする場合、flex: 1; これによって、他の要素に影響を与えずに、画面幅に応じて、その領域は余ったスペースを埋める形で伸びてくれます。たぶん正確な説明ではないですが、おおよそこう認識しています。

今回は2か所で flex: 1; が使われています。まず、left-container に flex: 1; があります。right-container が固定幅なので、left-container は残った領域を可変で埋めてほしいです。title にも flex: 1; があります。これも icon に影響を与えずに、残った領域を埋めてほしいからです。

「他の要素に影響を与えずに」の考察

少し寄り道して、flex: 1; について深く理解していきます。キーワードは flex-basis: 0%; です。

もし、title の flex: 1; がない場合、アイコンの領域が width よりも狭くなってしまいます。

しかし、タイトルが短い場合は問題ありません。

この現象を自分もうまく言語化できないのですが、とりあえず、 flex 指定しない場合のデフォルト値が

flex-grow: 0;
flex-shrink: 1;
flex-basis: auto;

であり、flex: 1

flex-grow: 1;
flex-shrink: 1;
flex-basis: 0%;

のショートハンドであることは知っておく必要があります。また、width よりも flex-basis が優先されflex-grow: 1; だけを title に指定してもバグは直りません。

ここからは私の推測です。

タイトルが長すぎるとどの要素を縮めるかをブラウザが判断します。「縮める」なので flex-grow は今回関係ありません。flex: 1; を指定しないとき、icon と title はどちらもデフォルト値の flex-shrink: 1;flex-basis: auto; です。 一方、icon にだけ width 指定がありますが、これは flex-basis が優先されるため無視されるみたいです。両要素の flex-shrink flex-basis が対等なとき、ブラウザが平等に両方をいい感じに縮めようとします。その結果が icon が狭くなる現象につながっているようです。

title に flex: 1; を付けた場合。flex-shrink: 1 は変わりませんが、title だけ flex-basis: 0% になります。ブラウザは icon と title を対等だとみなさず、flex-basis が大きいほうが width まで大きさを保ってよいと判断するようです。その結果、「他の要素に影響を与えずに」title だけ領域いっぱいを占有するということです。

タイトルが別に長くなければ、どの要素を縮めるかという話にすらなず、icon は width の領域を確保します。

ここまで私の推測です(強調)。flex 周り難しい...

min-width: 0;

flex: 1; には min-width: 0; を付けないと、overflow: hidden; 指定しているにも関わらず、領域内にテキストが収まってくれなくなります。 これがこの記事の一番伝えたいことでした。

調べてみると、flex: 1;min-width: 0; はよくあるハマりポイントで、暗黙のうちにセットみたいな感じがします。ただ直る理由はよくわかりませんでした。なので前振りが長かった割に解説はできません... カナシイ

ないよりはましかと思って、ChatGPT くんによる簡単な解説を載せておきます。

Flexアイテムのデフォルトのmin-widthはautoなので、コンテンツ幅を守ろうとしてしまう。 それを0にすることで「どんなに小さくてもいいから収まって」と命令できる。

まとめ

  • 可変にしたい要素には flex: 1; を指定する
  • その上で、改行させずに text-overflow: ellipsis; する場合は min-width: 0; を付ける
  • width よりも flex-basis が優先されるが、その解釈はブラウザの気分

参考サイト

副助詞「だけ」と補助動詞「てしまった」を使ってテキスト上の業務連絡の往復を1回減らす

この記事は、業務中のチャットに数文字追加するあるいは変化させることで、情報量をぐっと増やそうという提案です。チャットではなくリアルの会話でも応用できるかもしれませんが、リアルであれば声のトーンや表情なども組み合わせてより正確に情報が伝わるはずです。それがないチャットだからこそのテクニックのお話です。

さらに自分はエンジニアなので、プログラムのコメントやテストラベルにも応用していきます。とはいえ、誰でも当てはめることができます。

記事の要約

  • エラーが500件になりました ⇒ エラーが500件だけになりました!
  • エラーが5000件に増加しました ⇒ エラーが5000件にまで増加してしまいました...
  • 副助詞と補助動詞を使って、他の人に事実だけでなく解釈も伝えたい
  • プログラム中のコメントやテストのラベルにも応用できる

チャット例① エラーが500件になりました

障害発生が発生してバグ修正をデプロイしたあとに、エラー数の推移を確認したAさん。

改善前

A「エラー件数が500件になりました」
B(普段と障害発生時の両方のエラー数を覚えてない、これって問題ない数値なんだろうか?)
B「500件というのはさっきよりも減ったんでしょうか?」
A「はい、減りました」
B「つまり問題ない?」
A「はい、問題は解決したように見えます」
B「であればよかったです」

この会話例はAさんの「エラー件数が500件になりました」という内容が、良いことなのか悪いことなのかが文章からだとわかりません。つまり事実しか伝えていません。Bさんはそのデータの解釈の仕方が気になり、Aさんに質問しています。

改善例① 正攻法

A「エラー件数が500件まで減りました。問題は解決しました。」
B(特に助太刀はいらなそうか。よかったよかった)

データの解釈の情報が足りないのであれば、単に補足すればいいという改善例がこちらです。これによってBさんはチャットをする手間が省けました。誰もがこの改善例のほうが適切であることに疑いはないと思います。

ここで終わりにはせず、さらに別で改善例をあげます。

改善例② 副助詞+ビックリマーク

A「エラー件数が500件だけになりました!」
B(特に助太刀はいらなそうか。よかったよかった)

「だけ」という副助詞を付けました。自分は現代文の授業で副助詞の授業が今でも印象的に残っています。当時の現代文の先生は副助詞のことを「ほかの文章が隠れている」として説明しました。つまり、「エラー件数が500件になった」という事実に加えて、「さっきよりもエラーが減った」という文章が暗に示されているのです。「だけ」という副助詞のおかげで、情報量が増えたんですね。

この例ではついでにビックリマークもつけています。そうすることによって、ポジティブなメッセージであることが伝わります。ここでは、問題が解決したのだろうと読み手は推測できますね。

もちろん改善例①のほうが直接的であり、より適切であると私も考えます。なので、改善前のメッセージを送信するくらいなら改善例②のほうがずっとマシ、意識できるなら改善例①にする。くらいの温度感になるでしょう。しかし、改善例②をメインで使う場面もありえます。

改善例②の応用例

作業ログスレ

例えば、自分が書き込んでいる作業ログスレです。Slackにはスレッド機能があります。そのスレッド機能を作業ログとしても使っている場合、メモ書き程度に文が雑になっているでしょう。「VSCodeをインストールする」「した」「次にsettings.jsonを編集する」などです。

雑は雑でも改善例②を意識することで、早期の問題解決につながる未来があるかもしれません。

A「発注数が500件になっている」
A「発注数が500件だけになっている...」

後者の方が副助詞「だけ」の効果によって何やら問題が起きていそうな匂いが漂い始めます。悪い内容なのでビックリマークではなく「...」にしてみました。もしあなたが新人の作業スレでこの文章を見たとき、声を掛けたくなりますか?

プログラム中のコメント

// 入力されたユーザー名をバリデーションする
if (!userValidator.isValidate(user)) {

例えば、こんなコメントがあるとします。もしかして、userValidator はユーザー名以外の要素についてバリデーションはしてくれないのだろうか?と疑問に思いましたか。ではコードを追いかけてみましょう。

とならないため、副助詞「だけ」を挿入します。

// 入力されたユーザー名だけをバリデーションする
if (!userValidator.isValidate(user)) {

これであれば、userValidator という名前のくせにユーザー名しかバリデーションしないのかい!とツッコミを入れることができ、コードを追いかける手間はなくなったと思います。あるいは、年齢もバリデーションしたいから userValidator を修正しようと早期にアクションを思い立つかもしれません。

テストのラベル

beforeEach(() => {
    /* うさぎレコードを2匹生成する */
});


test("うさぎの検索結果が1件になっている", () => {
    const result = searchRabbit();
    expect(result).toHaveLength(1);
});

よく見るテストラベルかと思います。副助詞「だけ」をつけたらどうなりますか。

beforeEach(() => {
    /* うさぎレコードを2件生成する */
});

test("うさぎの検索結果が1件だけになっている", () => {
    const result = searchRabbit();
    expect(result).toHaveLength(1);
});

一見「だけ」を付けてもたいして情報量が変わらないように見えます。しかし、読み手に「うさぎの検索結果が1件だけになっている」というラベルはテスト製作者がわざわざ「だけ」という副助詞を付けるほどには意図的であることが伝わります。もし「だけ」がないとき、「うさぎレコードが2件生成されているはずなのに、ここで1件しか返ってこないのは仕様なのか?それともテストラベルが間違っているのか?でもわざわざ toHaveLength(1) としているくらいだから、1件なのは仕様なのかもしれない。でもでも、toHaveLength(1) というテストだけみて、あとから他の誰かがテストラベルを読みやすいように書き換えただけで、テストが間違っているのかも?わからないから、コードを読むか...」となる可能性があります。

たった2文字でこの未来を避けられるのであれば、十分価値のある2文字だと思います。

一旦休憩

副助詞「だけ」の例だけでも、これだけ誰かの手間を省ける可能性があります。自分はこれを再発見してもらいたくてこの記事を書きました。

副助詞は他にもたくさんありますよ。

日本語の単語(副助詞)

  • は、
    • ここには、何もない。(他と区別)
    • 会社に着くまで、1時間もかかる。(協調)
  • でも
    • コーヒーでも飲みましょう。(例示)
  • しか
    • 一つしかない。(限定)
  • ばかり
    • 着いたばかりだ。(完了)
  • まで
    • 学校まで歩く。(限度)
  • のみ
    • お支払いは、現金のみです。(限定)

チャット例② エラーが5000件に増加しました

エラーの増加を織り込み済みでリリースしたあとに、エラー数の推移を確認したAさん。

改善前

A「エラーが5000件に増加しました」
B(あれ?エラーが増えるとは聞いてたけどちょっと多すぎないか?)
B「なんか思ったより多い気がするんですが、問題ないでしょうか」
A「いえ、問題あります。想定していたエラー数は500件程度でした」
B「ちょっと通話で相談しましょう」

チャット例①と同じように、Aさんの「エラーが5000件になりました」は事実しか伝えておらず、その解釈の仕方がBさんに伝わりませんでした。

改善例③ 正攻法

A「エラーが5000件に増加しました。これは想定の500件よりもずっと多くて、問題あります。どなたか一緒に原因箇所見てくれないでしょうか」
B「ちょっと通話で相談しましょう」

改善例①と同じように、すべてAさんが聞かれる前に伝える方法です。後述の改善例④よりも情報が正確です。それでもなお改善例④を見ていきましょう。

改善例④ 副助詞+補助動詞+...

A「エラーが5000件にまで増加してしまいました...」
B「ちょっと通話で相談しましょう」

今回は副助詞「まで」と補助動詞「しまった」を付け加えました。補助動詞については後ほど補足しますが、「しまった」はAさんの非意図を伝えます。これによって、5000件の増加がAさんの意図したものではないことが伝わります。おまけで「...」もつけてあげました。

改善例③とは違って、緊急事態感までは伝えることはできませんが、改善前と比べれば情報量が増えていて、Bさんが相談すべきだという判断の助けになったことは確かです。

改善例④の応用例

改善例②の応用例と似ているので、パパっと紹介します。

作業ログスレ

A「開発環境の管理画面がインターネットから見える」
A「開発環境の管理画面がインターネットから見えてしまっている

後者には先輩によるヘルプが必要だとすぐにわかります。

プログラム中のコメント

# 簡易化のため、リスト全体をスキャンする
# 簡易化のため、リスト全体をスキャンしてしまった

後者の方が「いい方法思いついたら誰か直してほしい」という願いが読み取れます。

テストのラベル

describe("ユーザーが3桁の年齢を入力する", () => {
describe("ユーザーが3桁の年齢を入力してしまった", () => {

前者のラベルだと、読み手は「システムは3桁の年齢も考慮されているんだな」と思うでしょう。後者だと「システムは3桁の年齢は仕様にない」と思うでしょう。

補助動詞とは

もともと「てしまった」というノウハウだけ自分の中で持っていて、それを記事にするために ChatGPT と壁打ちして、補助動詞という言葉を知りました。なので補助動詞はこの記事の後付けです。

補助動詞とは、他の語について補助的な役割で使われる動詞

補助動詞(形式動詞)とは?使い方と通常の動詞との違いを一覧でわかりやすく解説!【例文で学ぶ 日本語文法】

他にも次のような表現があります。

  • (して)いる
  • (して)ある
  • (して)おく
  • (して)いく
  • (して)くる

このあと紹介する補助動詞が、もし補助動詞でなかったらすみません...

副助詞と補助動詞のそれ以外の例

A「集計スクリプトは1分かかりました」
A「集計スクリプトは1分かかりました」

A「クレカが決済方法に対応しています」
A「クレカのみが決済方法に対応しています」

A「バックアップを取りました」
A「バックアップを取っておきました

後者の方が「Aさん自身がバックアップを取ることは予定ではなかった」ことが暗に伝わります。

A「バグは修正しません」
A「バグは修正しないでおきます

後者の方が一旦修正しないというニュアンスが伝わります。

A「実装します」
A「実装してみます

後者の方がチャレンジ感がでて、失敗する可能性を認識していることが伝わります。つまり、あとからヘルプがでる可能性を示唆します。

A「EC2インスタンスに終了保護が掛かっています」
A「EC2インスタンスに終了保護が掛けてあります

後者の方が、終了保護の理由が忘れさられているわけではなく、現在も意図されているものであることが伝わります。

まとめ

文章のちょっとした語尾(補助動詞)や副助詞を変えるだけで、情報が正確になって無駄なやりとりや無駄な作業が減ります。 文章例①と文章例③のほうが適切な状況が多いことは念頭におきながら、ラフな場で使ってみるのはどうでしょう!

自分の zsh + powerline10k + peco の設定例

Windows 11 の Ubuntuzsh に prezto と powerline10k と peco の設定した記録を残します。完全に自分用の忘備録です。

前提

この記事でできるようになること

  • prezto で zsh でのコマンドのサジェストとコマンドのシンタックスハイライトが作るようになる
  • powerline10k でポチポチしてるだけで自分好みのプロンプトテーマになる
  • peco でコマンドヒストリを一覧表示できるようになる

各種設定

zsh の確認

現在のシェルが zsh になっていることを確認。

% echo $SHELL
/usr/bin/zsh

なっていなければ、zsh のパスに変更。

chsh -s /usr/zsh
# chsh -s /usr/bin/zsh でもよい

exec zsh -l

Prezto のインストール

Prezto は zsh の設定をするためのツール。このあとの Powerlevel10k の設定とサジェストとシンタックスハイライトのためにインストールする。

https://github.com/sorin-ionescu/prezto?tab=readme-ov-file#installation

git clone --recursive https://github.com/sorin-ionescu/prezto.git "${ZDOTDIR:-$HOME}/.zprezto"

# 念のため zsh 関連ファイルをバックアップ
cp ~/.zshrc ~/.zlogin ~/.zlogout ~/.zpreztorc ~/.zprofile ~/.zshenv /tmp

# 実行前に関連ファイルは削除しないとエラーが出る
rm ~/.zshrc ~/.zlogin ~/.zlogout ~/.zpreztorc ~/.zprofile ~/.zshenv

# github の手順からコピペと実行
setopt EXTENDED_GLOB
for rcfile in "${ZDOTDIR:-$HOME}"/.zprezto/runcoms/^README.md(.N); do
  ln -s "$rcfile" "${ZDOTDIR:-$HOME}/.${rcfile:t}"
done

exec $SHELL -l

カラフルなシェルが表示されればインストール成功。

Powerlevel10k のインストール

Powerlevel10k は Prezto で扱えるプロンプトテーマ設定ツール。

https://github.com/romkatv/powerlevel10k?tab=readme-ov-file#getting-started

最初はフォントのダウンロード。公式も推奨している。

https://github.com/romkatv/powerlevel10k?tab=readme-ov-file#manual-font-installation

4つのフォントをクリックするとダウンロードされるので、それぞれ実行して、インストールボタンを押す。

Ubuntu の設定を開き、既定値 > 外観 > フォントフェイス から先ほどインストールした「MesloLGS NF」を設定→保存する。

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ~/powerlevel10k
echo 'source ~/powerlevel10k/powerlevel10k.zsh-theme' >>~/.zshrc

exec $SHELL -l

シェルを再起動すると Powerlevel10k のプロンプト設定が開くので、適当に設定する。

自分はこんな感じの見た目になった。シンプルなのが好き。

Prezto で自動保管とシンタックスハイライトを有効化する

Prezto を使っていると設定ファイルにすでにいい感じの設定例がコメントアウトされている。

vim ~/.zpreztorc

~/.zpreztorc を編集。

# Set the Prezto modules to load (browse modules).
# The order matters.
zstyle ':prezto:load' pmodule \
  'environment' \
  'terminal' \
  'editor' \
  'history' \
  'directory' \
  'spectrum' \
  'utility' \
  'completion' \
  'history-substring-search' \
  'prompt' \
  'autosuggestions' \ # <-- 追加
  'syntax-highlighting' # <-- 追加#
# Syntax Highlighting
#

# Set syntax highlighters.
# By default, only the main highlighter is enabled.
zstyle ':prezto:module:syntax-highlighting' highlighters \  # コメントアウトを外す
  'main' \
  'brackets' \
  'pattern' \
  'line' \
  'cursor' \
  'root'

# Set syntax highlighting styles.
# zstyle ':prezto:module:syntax-highlighting' styles \
#   'builtin' 'bg=blue' \
#   'command' 'bg=blue' \
#   'function' 'bg=blue'

# Set syntax pattern styles.
zstyle ':prezto:module:syntax-highlighting' pattern \  # コメントアウトを外す
  'rm*-rf*' 'fg=white,bold,bg=red'
exec $SHELL -l

コマンドに色がついてサジェストも出るようになった。

peco のインストール

peco を使ってコマンドヒストリを一覧・フィルタリングできるようにする。

https://github.com/peco/peco?tab=readme-ov-file#installation

sudo apt install peco
vim ~/.zshrc

.zshrc の末尾に以下を追加。

# C-R: peco-history-selection
function peco-history-selection() {
    BUFFER=$(\history -nr 1 | peco --layout=bottom-up)
    CURSOR=${#BUFFER}
    zle reset-prompt
}

zle -N peco-history-selection
bindkey '^R' peco-history-selection
source ~/.zshrc

Ctrl-R で過去のヒストリを一覧表示できるようになった。

emacs の設定

正直記事の趣旨からすると蛇足だが、自分は emacs を簡単なファイル編集で使うので、設定する。

sudo apt install emacs
vim ~/.emacs

emacs の設定ファイルは .emacs.emacs.d フォルダ。

;; *.~ とかのバックアップファイルを作らない
(setq make-backup-files nil)
;; .#* とかのバックアップファイルを作らない
(setq auto-save-default nil)
;; スクロールを1行ずつ
(setq scroll-step 1)
;; 行番号・桁番号をモードラインに表示する
(line-number-mode t)
(column-number-mode t)
;; スタートアップメッセージを非表示
(setq inhibit-startup-message t)
vim ~/.zshrc

Ubuntu 上では emacsGUI ではなくターミナル上で起動させたいので、emacs と打つだけでそうなるように alias を張る。

alias emacs='emacs -nw'
source ~/.zshrc

参考