Workflow Emacs untuk review kode, lint, dan Git yang lebih cepat bukan soal mengubah Emacs menjadi IDE raksasa, tetapi soal merangkai fitur bawaan dan beberapa paket penting agar tugas harian developer terasa lebih pendek jalurnya. Jika tujuan Anda adalah membuka proyek, mencari simbol atau file, menjalankan lint, meninjau diff, lalu commit tanpa bolak-balik aplikasi, Emacs sangat kuat untuk pola kerja ini.

Dalam konteks Emacs 31, arah pengembangannya makin menegaskan dua hal yang relevan untuk workflow harian: fitur bawaan makin matang, dan integrasi dengan tool eksternal tetap menjadi kekuatan utama. Artinya, Anda tidak harus memasang terlalu banyak paket. Setup minimum yang disiplin justru biasanya lebih stabil, lebih mudah dipindahkan ke mesin lain, dan lebih cocok dipakai dalam tim.

Prinsip dasar: biarkan Emacs mengorkestrasi, tool eksternal mengeksekusi

Kesalahan umum saat mulai memakai Emacs adalah mencoba memindahkan semua logika ke dalam editor. Untuk workflow developer modern, pendekatan yang lebih sehat adalah:

  • Emacs untuk navigasi, review, editing, diff, dan orkestrasi perintah.
  • Tool proyek untuk kebenaran teknis: formatter, linter, test runner, build tool, dan Git.
  • Konfigurasi proyek sebagai sumber aturan, bukan konfigurasi editor personal.

Kenapa pendekatan ini bekerja? Karena hasil lint, format, dan test akan konsisten antara editor lokal, terminal, dan CI. Emacs menjadi antarmuka kerja yang cepat, tetapi tidak menjadi sumber perilaku yang berbeda dari pipeline tim.

Setup minimum yang realistis

Untuk kasus review kode, linting, pencarian proyek, dan Git, Anda tidak perlu memulai dari distribusi Emacs yang kompleks. Setup minimum yang realistis biasanya mencakup:

  • Fitur bawaan untuk proyek, pencarian, buffer, dan shell.
  • Magit untuk Git.
  • Satu mekanisme completion dan navigasi yang Anda nyaman pakai.
  • Integrasi lint/format yang memanggil tool eksternal dari proyek.

Fitur bawaan yang sebaiknya dipakai dulu

  • project.el untuk mengenali root proyek dan menjalankan perintah berbasis proyek.
  • xref untuk jump to definition/references jika backend bahasa mendukung.
  • grep/rgrep atau integrasi pencarian cepat ke ripgrep.
  • compile untuk menjalankan lint, test, atau build dan melompat ke error.
  • vc untuk operasi version control dasar jika belum memasang Magit.
  • dired untuk eksplorasi file dan operasi batch.
  • eglot jika Anda memang membutuhkan LSP, tanpa setup terlalu berat.

Di Emacs modern, kombinasi fitur bawaan ini sudah cukup kuat. Emacs 31 juga melanjutkan tren perbaikan kualitas hidup di area completion, help, dan integrasi bawaan, jadi banyak workflow yang dulu terasa “perlu paket tambahan” sekarang bisa dimulai dari dasar yang lebih bersih.

Contoh setup awal yang sederhana

Contoh berikut sengaja tidak terlalu agresif. Tujuannya adalah memberi fondasi yang mudah dipahami dan mudah direproduksi.

(require 'project)
(require 'compile)
(require 'dired)
(require 'eglot nil t)

;; Simpan backup dan auto-save di lokasi terpusat agar repo tetap bersih
(setq backup-directory-alist '(("." . "~/.emacs.d/backups")))
(setq auto-save-file-name-transforms '((".*" "~/.emacs.d/auto-save/" t)))

;; Gunakan command pencarian cepat bila ripgrep tersedia
(when (executable-find "rg")
  (setq grep-command "rg -nH --no-heading "))

;; Format buffer dengan tool proyek melalui shell-command
(defun my/format-buffer()
  "Format buffer menggunakan formatter proyek jika ada."
  (interactive)
  (cond
   ((executable-find "prettier")
    (shell-command-on-region (point-min) (point-max) "prettier --stdin-filepath /dev/stdin" nil t))
   (t
    (message "Formatter tidak ditemukan di PATH"))))

(global-set-key (kbd "C-c p f") #'project-find-file)
(global-set-key (kbd "C-c p g") #'rgrep)
(global-set-key (kbd "C-c c") #'compile)
(global-set-key (kbd "C-c f") #'my/format-buffer)

Contoh di atas bukan konfigurasi final untuk semua bahasa. Yang penting adalah polanya: gunakan fitur proyek bawaan, panggil tool dari environment proyek, dan ikat ke shortcut yang mudah diingat.

Pencarian proyek dan review kode yang cepat

Saat review kode, bottleneck utamanya biasanya bukan mengetik, melainkan context switching: pindah file, mencari penggunaan fungsi, membuka diff, lalu kembali ke file awal. Emacs unggul karena hampir semua tindakan itu bisa dilakukan dari keyboard dengan model interaksi yang konsisten.

Workflow pencarian yang efisien

Untuk membaca perubahan dengan cepat, Anda biasanya butuh tiga jenis pencarian:

  1. Cari file: buka file berdasarkan nama dari root proyek.
  2. Cari teks: temukan string, TODO, error message, query, atau simbol yang belum terindeks.
  3. Cari definisi/referensi: lompat ke definisi dan lihat siapa yang memakainya.

Urutan praktisnya bisa seperti ini:

  • Pakai project-find-file untuk membuka file terkait perubahan.
  • Pakai rgrep atau rg untuk mencari simbol, endpoint, atau config key yang sama di seluruh repo.
  • Pakai xref-find-definitions dan xref-find-references jika bahasa dan backend mendukung.

Kenapa kombinasi ini efektif? Karena tidak semua pencarian harus melalui LSP. Untuk banyak kasus review, pencarian teks biasa justru lebih andal: misalnya saat mencari penggunaan env var, nama migration, string SQL, atau payload JSON.

Review diff tanpa keluar dari editor

Review kode yang cepat sangat bergantung pada kemampuan membaca diff sambil tetap melihat konteks file. Di Emacs, Anda bisa menggabungkan beberapa pendekatan:

  • Magit diff untuk melihat perubahan staged/unstaged dan history commit.
  • ediff bila butuh perbandingan yang lebih detail antar revisi atau file.
  • vc-region-history atau blame tool sesuai kebutuhan untuk menelusuri perubahan baris tertentu.

Untuk review PR lokal, alur yang umum adalah checkout branch, buka status di Magit, lihat diff per file, lalu gunakan jump ke file untuk memeriksa konteks implementasi di luar potongan diff. Ini lebih cepat daripada hanya membaca diff statis di web UI saat perubahan melibatkan beberapa lapisan aplikasi.

Linting dan formatting: prioritaskan tool proyek, bukan perilaku editor

Untuk linting, target utamanya adalah hasil yang sama antara Emacs, terminal, dan CI. Karena itu, lebih aman menjalankan linter yang memang dipakai proyek, bukan bergantung pada aturan editor lokal yang bisa berbeda.

Dua pola integrasi yang paling praktis

Pola 1: jalankan lewat compile

Ini cocok jika proyek sudah punya command standar seperti make lint, npm run lint, poetry run ruff check, atau cargo clippy. Emacs akan menangkap output, mengenali lokasi error, lalu memungkinkan Anda lompat ke file dan baris terkait.

(defun my/project-lint ()
  "Jalankan lint proyek dari root proyek."
  (interactive)
  (let ((default-directory (project-root (project-current t))))
    (compile "make lint")))

(global-set-key (kbd "C-c l") #'my/project-lint)

Pola 2: format saat simpan, tetapi hanya jika aman

Format-on-save nyaman, tetapi tidak selalu cocok. Untuk repo besar atau formatter lambat, ia bisa mengganggu ritme kerja. Gunakan hanya jika:

  • formatter sudah menjadi standar tim,
  • hasilnya deterministik,
  • waktu eksekusinya cukup cepat,
  • dan tidak sering mengubah bagian file yang tidak sedang Anda sentuh.

Contoh yang lebih aman adalah membatasi formatter berdasarkan mode atau repo tertentu, bukan mengaktifkannya secara global.

Contoh integrasi lint yang lebih reproducible

Daripada memanggil binary global langsung, usahakan memanggil command yang mengikuti dependency proyek. Misalnya:

  • JavaScript/TypeScript: npm run lint atau pnpm lint
  • Python: poetry run ruff check . atau uv run ...
  • Go: go test ./... atau command lint yang didefinisikan tim
  • Rust: cargo fmt --check dan cargo clippy

Keuntungannya adalah versi tool dan opsi yang dipakai mengikuti lockfile atau environment proyek, bukan asumsi mesin lokal developer.

Kesalahan umum saat menghubungkan linter ke Emacs

  • PATH berbeda antara shell interaktif dan Emacs GUI, sehingga binary tidak ditemukan.
  • default-directory salah, jadi command berjalan bukan dari root proyek.
  • Parsing error output tidak standar, sehingga Emacs tidak bisa lompat ke lokasi file.
  • Formatter global menghasilkan output berbeda dari formatter yang dipakai CI.

Jika lint atau format bekerja di terminal tetapi gagal di Emacs, pertama cek PATH, working directory, dan command yang benar-benar dijalankan oleh Emacs. Tiga hal ini lebih sering menjadi sumber masalah daripada paket editornya sendiri.

Magit untuk alur Git harian yang lebih cepat

Kalau hanya satu paket tambahan yang harus dipasang untuk workflow ini, pilihannya hampir selalu Magit. Alasan utamanya sederhana: ia membuat operasi Git yang kompleks terasa seperti serangkaian langkah kecil yang bisa dilihat, dibatalkan, dan diulang dengan aman.

Alur dasar yang paling berguna

Dengan Magit, alur Git harian biasanya menjadi:

  1. Buka status repo.
  2. Lihat file modified, untracked, staged, dan unstaged.
  3. Buka diff per hunk.
  4. Stage hanya bagian yang relevan.
  5. Tulis commit message.
  6. Review ulang history jika perlu.
  7. Push atau buat branch baru.

Keunggulan nyatanya ada di tahap review sebelum commit. Stage per hunk membantu memisahkan perubahan fungsional dari noise seperti format atau logging tambahan. Ini sangat penting untuk code review tim karena commit menjadi lebih mudah dibaca dan lebih aman di-revert.

Contoh kebiasaan kerja dengan Magit

  • Sebelum commit: buka diff staged dan pastikan tidak ada file rahasia, debug print, atau perubahan formatting massal yang tidak disengaja.
  • Saat review bugfix: gunakan blame atau telusuri commit terkait untuk memahami kenapa kode sebelumnya dibuat seperti itu.
  • Saat rebase: lakukan dari Magit agar konflik, status branch, dan diff tetap terlihat dalam satu tempat.

Magit juga bagus untuk pekerjaan yang biasanya terasa “berisiko” di command line, seperti stashing sebagian perubahan, amending commit terakhir, atau cherry-pick commit tertentu. Bukan karena Git CLI buruk, tetapi karena Magit memberi representasi status repo yang sangat jelas di layar.

Kapan tetap pakai Git CLI?

Meski Magit sangat kuat, Git CLI tetap berguna untuk:

  • otomasi di shell script,
  • diagnosis masalah environment,
  • command yang sangat spesifik dan jarang dipakai,
  • atau saat bekerja di server tanpa workflow editor penuh.

Pendekatan yang sehat bukan memilih salah satu secara fanatik, melainkan memakai Magit sebagai antarmuka utama dan CLI sebagai alat pelengkap.

Contoh workflow tim: dari review lokal sampai CI

Berikut contoh workflow yang realistis untuk tim backend/frontend yang ingin menjaga konsistensi antara Emacs lokal dan pipeline:

1. Standarkan command proyek

Di root repo, sediakan command yang jelas, misalnya lewat Makefile atau task runner lain:

lint:
	pnpm eslint .

format:
	pnpm prettier --check .

test:
	pnpm test

review:
	pnpm eslint . && pnpm test

Emacs lalu cukup memanggil make lint, make test, atau make review. Ini lebih mudah dirawat daripada menanam semua detail command di konfigurasi editor setiap anggota tim.

2. Emacs sebagai antarmuka lokal

  • Buka file dan simbol dari root proyek.
  • Jalankan lint/test lewat compile.
  • Lompat ke error langsung dari buffer hasil compile.
  • Review diff dan commit dengan Magit.

3. CI memverifikasi command yang sama

Pipeline CI sebaiknya memanggil command yang identik atau setara secara eksplisit. Dengan begitu, “lolos di editor” tidak menjadi kondisi yang berbeda dari “lolos di CI”. Ini inti reproducibility.

4. Reviewer memakai local branch untuk kasus tertentu

Untuk perubahan yang kompleks, reviewer bisa checkout branch pengusul, membuka diff di Magit, lalu menelusuri referensi silang di seluruh repo. Ini sangat membantu untuk PR yang menyentuh banyak modul, migration database, atau perubahan API lintas layer.

Trade-off: kapan Emacs cocok, kapan tidak

Emacs cocok jika

  • Anda sering bekerja di banyak repo atau banyak bahasa dengan pola kerja serupa.
  • Anda menghargai workflow keyboard-centric dan minim context switching.
  • Anda ingin menggabungkan editing, review diff, shell, dan Git dalam satu antarmuka.
  • Tim Anda sudah punya command proyek yang jelas untuk lint, format, dan test.

Emacs kurang cocok jika

  • Anda membutuhkan dukungan GUI spesifik dari vendor tools yang tidak nyaman dijembatani ke editor.
  • Tim sangat bergantung pada fitur IDE tertentu yang sangat terintegrasi dan sulit diganti.
  • Anda belum siap meluangkan waktu untuk memahami shortcut, buffer model, dan dasar konfigurasi Emacs.
  • Kebutuhan utama Anda sebenarnya hanya edit cepat sesekali, bukan workflow harian yang dalam.

Trade-off terbesarnya adalah kurva belajar. Emacs bisa sangat cepat setelah terbiasa, tetapi minggu-minggu pertama sering terasa lambat. Karena itu strategi adopsi bertahap lebih penting daripada mengejar setup sempurna sejak awal.

Tips adopsi bertahap agar tidak berhenti di tengah jalan

  1. Mulai dari satu use case: misalnya Git dengan Magit, tanpa mengubah editor utama untuk coding penuh.
  2. Tambahkan pencarian proyek: pelajari project-find-file, grep, dan xref.
  3. Masukkan lint/test: gunakan compile dengan command proyek yang sudah ada.
  4. Baru tambah LSP jika perlu: jangan jadikan LSP sebagai syarat awal untuk semua bahasa.
  5. Simpan konfigurasi di repo dotfiles: hindari edit manual yang sulit direproduksi.

Adopsi bertahap bekerja karena tiap lapisan memberi nilai langsung. Anda tidak perlu menunggu sampai Emacs menjadi “IDE lengkap” untuk mendapatkan manfaat.

Checklist reproducible untuk mesin lokal dan CI

Agar workflow Emacs tidak menjadi setup personal yang rapuh, gunakan checklist berikut:

  • Gunakan command proyek untuk lint, format, dan test.
  • Pastikan formatter/linter terkunci melalui lockfile, dependency manager, atau toolchain proyek.
  • Dokumentasikan dependency editor minimum: misalnya Emacs, Magit, dan apakah perlu Eglot.
  • Simpan konfigurasi Emacs di dotfiles dan versi-kan jika relevan.
  • Hindari binary global yang tidak konsisten dengan versi di proyek.
  • Pastikan PATH Emacs benar, terutama jika memakai GUI di macOS atau Linux desktop.
  • Uji command yang sama di terminal dan Emacs jika ada perbedaan hasil.
  • Buat target CI yang eksplisit seperti make lint, make test, atau make review.
  • Jangan campur rule editor dengan rule proyek untuk format dan lint.

Penutup

Workflow Emacs untuk review kode, lint, dan Git yang lebih cepat paling efektif saat Anda menahannya tetap sederhana: fitur proyek bawaan untuk navigasi, command proyek untuk lint dan test, serta Magit untuk review dan commit. Dengan pola ini, Emacs berfungsi sebagai pusat kerja harian yang cepat tanpa menciptakan perilaku yang berbeda dari terminal atau CI.

Jika Anda baru mulai, jangan kejar semua fitur sekaligus. Mulailah dari Magit dan pencarian proyek, lalu tambahkan linting dan formatting yang mengikuti aturan repo. Hasil terbaik biasanya datang bukan dari konfigurasi paling panjang, melainkan dari setup yang kecil, stabil, dan konsisten dipakai setiap hari.