What are your favorite Emacs packages?
lobste.rs · 2026-04-22
Lobste.rs 上一篇由 jussi 發起的討論串引爆了 Emacs 社群的集體回憶：「讀到有人把 Emacs 當網頁瀏覽器在用，我就想知道大家真正離不開的套件到底是什麼？」短短幾小時內湧現數十則高品質留言，從補全框架、郵件客戶端到終端模擬器，幾乎呈現了一幅當代 Emacs 生態系的全景圖。
補全框架：現代 Emacs 的核心基礎建設
最高頻出現的組合是 vertico + orderless + marginalia + consult，這四個套件構成了當今 Emacs 最主流的「小型補全堆疊」（small completion stack）。
- vertico：以垂直列表呈現 minibuffer 補全選項，取代原生的水平展示方式。
- orderless：補全時支援空格分隔的多重模糊匹配，輸入順序不拘，對搜尋長檔名或指令名稱極為方便。
- marginalia：在補全列表右側顯示額外元資訊，例如指令說明、檔案大小、修改時間等。
- consult：基於上述補全框架，提供強化版的 switch-to-buffer、grep、find-file 等命令，並支援即時預覽（live preview）。
vfoley 直白地說：「這個補全堆疊把一切都改變了。」aloys 更進一步補充，正是 mu4e、org mode + org-roam、elfeed、ediff、meow 這幾個套件讓他從 Neovim 徹底轉換到 Emacs，而完成這場跳躍後，Magit 的「深度整合哲學」讓他更加回不去了。
Magit：幾乎無人反對的最佳 Git 介面
討論串中 Magit 幾乎是每隔幾則留言就出現一次的名字。它並非單純的 Git 命令包裝，而是以 Emacs buffer 為中心設計了一套互動式 Git 工作流——staging、commit、rebase、cherry-pick、blame 都可以在同一介面裡完成，且與 Emacs 的按鍵系統深度整合。許多人認為 Magit 是「Emacs 中 killer app 的最佳案例」，也常被外部開發者列為「唯一讓我考慮學 Emacs 的理由」。
郵件與 RSS：Emacs 作為資訊中心
Shorden 和 aloys 都強調了 mu4e（基於 mu 的郵件客戶端）與 Elfeed（RSS/Atom 閱讀器）的重要性。mu4e 依賴 mu 這個用 C 寫成的高效郵件索引工具，在本地建立搜尋索引後，可以在 Emacs 中以毫秒級速度搜尋幾十萬封郵件。Elfeed 則以 Org mode 風格的過濾器（filter）讓 RSS 訂閱變得可程式化——想只看特定標籤、特定時間範圍的文章，只需一行 Elisp。
technomancy 另外推薦了內建的 ERC（IRC 客戶端）與 eshell（純 Elisp 實作的 shell），以及 eglot——Emacs 29 正式內建的 LSP 客戶端。他認為 eglot 讓 Emacs 與「文字編輯器」和「IDE」之間的界線真正消弭。
模態編輯：Kakoune 風格的 meow
多位留言者提到 meow 這個相對較新的模態編輯套件。不同於 evil-mode（模擬 Vim）或 god-mode，meow 採用了接近 Kakoune 的設計哲學：「先選取，再操作」（selection-first），所有動作都作用在已選取的區域上。fluent 稱其為「Emacs 中最好的模態體驗，比 Kakoune 本身更順手」。
效能與顯示：細節決定體驗
Shorden 特別點名 gcmh（Garbage Collector Magic Hack）——這個套件的核心思路是：在 Emacs 空閒時降低 GC 閾值，讓垃圾回收靜悄悄地在背景執行；在使用者主動操作時提高閾值，避免 GC 在關鍵時刻觸發而造成卡頓。對於大量使用 Elisp 套件的重度使用者，gcmh 能明顯減少「感知 GC 延遲」。另外 vlf（Very Large Files）讓 Emacs 可以打開超大檔案而不會耗盡記憶體，ultra-scroll 則改善了滾動的流暢度。
grym 分享的清單包含幾個鮮為人知的寶貝：dired-preview（在 dired 中即時預覽選取的檔案）、dwim-shell-command（以「Do What I Mean」邏輯封裝常用 shell 指令）、eat（Emulate A Terminal，比 vterm 更接近完整 xterm 相容性的終端模擬器）。
其他值得關注的套件
- org-roam：基於 Org mode 的雙向連結筆記系統，類似 Roam Research 的 Emacs 實作。
- paredit：Lisp 程式設計必備，確保括號永遠成對，並提供結構化移動與編輯。
- diff-hl：在 fringe（編輯區左側邊緣）即時顯示 Git diff 狀態，比 git-gutter 更輕量。
- Avy：以字元跳轉的方式替代滑鼠，輸入兩個字母即可跳到可見螢幕上的任意位置。
- super-save：在切換 buffer 或失去焦點時自動儲存，讓「記得按 Ctrl-S」成為歷史。
- exwm：把 Emacs 變成 X11 視窗管理器，從此一切皆在 Emacs 中。
這個討論串告訴我們什麼？
從整體留言模式來看，2026 年的 Emacs 社群已高度收斂在幾個核心範式上：以 vertico 系補全框架取代 Helm/Ivy、以 eglot 取代 lsp-mode 作為主流 LSP 客戶端、以 meow 作為 evil-mode 的輕量替代。同時，Emacs 作為「資訊中樞」（郵件 + RSS + 終端 + 筆記）的定位依然強健，而不只是一個文字編輯器。對於想嘗試 Emacs 的工程師，technomancy 推薦的 better-defaults 套件是最好的起點——它只做一件事：把 Emacs 的預設設定調整成更合理的狀態，讓你少踩幾十個坑。
168.95.192.1 擋 ICMP 結束了...
blog.gslin.org · 2026-04-22
台灣最大 ISP 中華電信旗下的 Hinet，其 DNS 伺服器 168.95.192.1 從 2026 年 4 月 21 日 15:47:27 開始封鎖 ICMP 封包，並於隔日 2026 年 4 月 22 日 16:04:27 恢復正常，整起事件持續了整整 24 小時 17 分鐘。部落客 Gea-Suan Lin 以監控圖表紀錄了這段始末，並在文末輕描淡寫地加上一句：「本來以為應該會變成常態？」
168.95.192.1 是什麼？
168.95.192.1 是中華電信 Hinet 提供的公共 DNS 遞迴伺服器，長期以來是台灣用戶最廣泛使用的 DNS 解析點之一，地位類似 Google 的 8.8.8.8 或 Cloudflare 的 1.1.1.1。由於知名度極高、使用率廣泛，它的任何異常行為都會立即引起網路工程師的注意。
什麼是 ICMP 封鎖，為什麼重要？
ICMP（Internet Control Message Protocol）是 IP 網路的基礎診斷協定，ping 和 traceroute（或 tracert）都依賴它運作。當一個重要的 DNS 伺服器封鎖 ICMP 時，會發生幾件事：
ping 168.95.192.1完全沒有回應，無法判斷主機是否存活。traceroute在抵達該 IP 時路徑會中斷，難以追蹤封包路由。- 依賴 ICMP unreachable 訊息的 Path MTU Discovery 機制可能失效，導致某些連線出現神祕的效能問題。
- 網路監控系統（如 Nagios、Zabbix、Prometheus blackbox exporter）若以 ICMP ping 作為健康檢查手段，會誤判該 DNS 伺服器為「宕機」。
值得注意的是，DNS 本身（UDP/TCP port 53）在封鎖期間仍正常運作——使用者的域名解析並未受到影響，只有診斷工具失靈了。
為什麼 ISP 或 DNS 業者會封鎖 ICMP？
封鎖 ICMP 是一個有爭議但並不罕見的操作決定，常見理由包括：
- DDoS 防禦：ICMP flood 是早期常見的 DoS 攻擊手法，封鎖 ICMP 可以降低被用作反射放大攻擊的風險。
- 降低 CPU 負載：大流量的 ICMP ping 請求需要核心處理，封鎖可節省資源。
- 隱匿存在：讓主機不響應 ping 可以降低被掃描器發現的可能性（雖然安全效益有限）。
然而，RFC 1122 明確建議主機應回應 ICMP echo request，而 RFC 4890 也提供了 IPv6 下 ICMP 過濾的最佳實踐指引——完全封鎖 ICMP 通常被視為過激行為。
24 小時之謎
這次事件最耐人尋味的地方在於：封鎖精確維持了約 24 小時後自動解除。這個模式暗示可能是某種自動化防禦系統觸發了臨時封鎖——例如偵測到異常流量後啟動黑洞路由，並在一段冷卻時間後自動恢復。也可能是維護視窗、設備韌體更新，或是人為設定的測試。Gea-Suan Lin 的部落格過去多次記錄 Hinet 基礎設施的行為，這次的詳細時間戳記正是長期監控的成果。
工程師可以學到什麼
這則短文背後有幾個值得深思的工程教訓：第一，長期監控的價值——沒有歷史數據就無法精確還原事件發生的時刻與持續時間；第二，不要依賴單一健康檢查指標，ICMP 可達性不等於服務正常；第三，DNS 伺服器的可觀測性很重要，即使只是 IP 層的 ICMP 行為變化，都可能影響大量依賴它的監控基礎設施。對於自己架設監控的工程師，可以嘗試用 Prometheus blackbox_exporter 同時監控 ICMP、DNS 查詢延遲與 TCP 443 連線，讓三個指標互相佐證，避免誤報。
MXmap
blog.gslin.org · 2026-04-22
Gea-Suan Lin 在這篇文章中介紹了一個名為 MXmap 的開源 OSINT（開放原始碼情報）專案。它的核心目的很單純：透過 DNS 的 MX 記錄與一系列自動化探測，找出歐洲各國市政府究竟把電子郵件交給哪家服務提供商來管理。結論令人玩味——Microsoft 在歐洲市政電子郵件市場的主導地位遠超想像。
這個專案在解決什麼問題？
電子郵件服務提供商的市場份額向來難以公開統計，因為沒有集中的登記系統。MXmap 的思路是：DNS 不說謊。每個使用自訂網域的組織都必須在 DNS 中設定 MX 記錄，指向其郵件伺服器。透過自動化查詢這些公開可查的 DNS 記錄，就能在大規模下推斷出「誰在幫誰收發郵件」。
以瑞士版本為例，專案以瑞士全國約 2,100 個市鎮為研究對象，分兩個階段進行：
Phase 1：域名解析
這個階段的挑戰在於：很多市鎮的官方網域並不是簡單的「市鎮名.ch」，需要多管齊下才能找到正確的郵件域名：
- 從 Wikidata 與 BFS（瑞士聯邦統計局）API 抓取所有市鎮清單，並套用人工修正表（manual overrides）。
- 爬取各市鎮官方網站，擷取出現的電子郵件地址。
- 根據市鎮名稱猜測可能的域名組合，再用 MX lookup 驗證是否有效。
- 對多個來源的結果進行加權評分，找出可信度最高的域名候選。
Phase 2：服務商識別
拿到域名後，系統對每個域名同時發起 10 個並發探測，蒐集各類證據：
- SPF 記錄：
v=spf1中列出的授權 IP 或 include 標籤直接洩漏服務商資訊。 - DKIM/DMARC：selector 名稱與 policy 的模式可用來辨識服務商。
- Autodiscover：Microsoft Exchange/Office 365 特有的自動設定端點。
- CNAME chain：追蹤 MX hostname 的 CNAME 鏈可以找到最終指向的服務商基礎設施。
- SMTP banner：直接連接 port 25，取得伺服器歡迎訊息。
- ASN 資訊：透過 IP 的自治系統號（Autonomous System Number）識別服務商。
- TXT 驗證記錄：Microsoft、Google 等服務商在 DNS TXT 中留下特徵性的 domain ownership verification 字串。
系統將所有探測結果加權彙總，計算出 0 到 100 的信心分數（confidence score），最終輸出 municipality_domains.json 和 data.json 兩個檔案。
結論：Microsoft 的市政電子郵件帝國
瑞士版本的結果顯示 Microsoft（Exchange Online / Microsoft 365）在市政電子郵件市場中佔有壓倒性優勢。類似的趨勢在其他已有對應版本的國家也得到印證——比利時、德國、法國、荷蘭、挪威、葡萄牙、瑞典、英國都有人用相同方法跑出了類似的市場圖像。
這個結果並不令人完全驚訝：Office 365 政府方案（GCC/GCC High）提供了資料主權保障、既有 AD 整合、IT 人員熟悉的管理介面，在缺乏足夠 IT 人力自行維護基礎設施的中小型市鎮中，選擇 Microsoft 外包是合理的行政決策。
工程師可以拿來做什麼？
MXmap 的方法論本身就是一套可複用的 DNS 情報框架。你可以用類似的技術：偵測競爭對手的技術棧遷移、稽核自家域名的 DNS 設定是否符合安全政策（SPF -all、DMARC p=reject）、或是在大規模網路安全研究中識別特定服務提供商的部署規模。GitHub 上的原始碼（davidhuser/mxmap）是很好的學習材料，特別是它的多來源加權評分邏輯值得參考。
Sure, xor'ing a register with itself is the idiom for zeroing it out, but why not sub?
devblogs.microsoft.com · 2026-04-21
Raymond Chen 的「The Old New Thing」部落格是微軟歷史最悠久的技術寫作之一，專門挖掘 Windows 與底層系統程式設計中那些「大家都這樣做但沒人說清楚為什麼」的細節。這次他把矛頭指向 x86 組合語言中一個看似微不足道的問題：為什麼清零暫存器要用 xor eax, eax 而不是 sub eax, eax？
兩條指令，功能完全相同
從數學角度看：
xor eax, eax：任何值與自己做 XOR，結果為 0。sub eax, eax：任何值減去自己，結果為 0。
兩者的機器碼長度相同，執行週期也相同，對於一般的程式邏輯而言完全可以互換。那麼，這到底只是習慣問題，還是有更深的技術理由？
旗標行為的微妙差異
x86 的算術指令會修改 EFLAGS 暫存器中的多個旗標位。兩者的差別只有一個：
xor eax, eax之後，AF（Auxiliary Flag）旗標是 undefined（未定義，由 CPU 實作決定）。sub eax, eax之後，AF 旗標明確被清零（因為沒有低 4-bit 進位）。
其他旗標（OF、SF、ZF、PF、CF）兩者行為相同：OF=0、SF=0、ZF=1、PF=1、CF=0。因此，從旗標的確定性來看，sub 反而更精確——這是 sub 在技術上的唯一優勢。
XOR 勝出的真正原因：雪球效應
Chen 的核心論點是：xor r, r 的勝出並非因為它技術上更優越，而是一個自我強化的市場動態（snowball effect）所造成的結果：
- 初始平衡：最早期，兩種寫法的使用頻率大致相當。
- 編譯器的選擇成為權威信號：當主流 C 編譯器開始選擇輸出
xor r, r時，廣大程式設計師把這個選擇解讀為「編譯器工程師一定知道什麼我不知道的事情」，進而跟進使用 XOR。 - 正回饋循環：XOR 越普及，越多人認為它是「正確」的寫法，越多程式碼採用它，越多後來者學到它。
- 硬體優化：Intel 最終在指令解碼階段為
xor r, r（以及後來的sub r, r）加入了特殊識別邏輯，將其視為「暫存器清零」的語義快捷路徑——處理器可以直接把目的暫存器重新命名（register renaming）到一個內部的「永久零值暫存器」，完全跳過執行單元，達到 zero-latency 執行。
Intel 後來也對 sub r, r 加入了同樣的優化，但這個時候 XOR 的地位已牢不可破。
跨平台的考量
Stack Overflow 上有人提出另一個實際理由：其他 CPU 廠商可能只特殊處理了 xor r, r，但沒有對 sub r, r 做同樣的優化。在需要跨 x86 相容 CPU（包括 AMD、VIA、早期 Intel 各世代）的程式碼中，選擇 XOR 是更保守、更安全的決定。
Itanium 的例外
Chen 也點到了 Itanium（IA-64）架構上的特殊情況：Itanium 的暫存器有一個額外的 NaT（Not-a-Thing）位元，用來標記該暫存器是否持有有效值。數學運算（包括 XOR 和 SUB）並不會重置 NaT 位元，因此如果來源暫存器帶有 NaT，兩種指令都無法正確清零。好在 Itanium 提供了一個專用的零值暫存器（r0），不需要任何清零技巧；直接讀取 r0 就等於讀取 0。
那位故意用 sub 的工程師
Chen 以一個有趣的軼事收尾：他有一位前同事刻意在所有組合語言程式碼中使用 sub r, r 而非 xor r, r，這讓他的程式碼在一大堆組語檔案中獨樹一幟，成了一種個人「程式碼簽名」。在功能完全相等的情況下，用少數派的寫法替自己的程式碼打上識別標記，是個相當工程師風格的幽默。
工程師的收穫
這篇文章是一個絕佳的案例，說明技術標準的形成往往不是純粹的技術選擇，而是社會動態（編譯器輸出 → 開發者跟進）、歷史路徑依賴（早期習慣固化）、以及後來硬體廠商的被動配合共同作用的結果。對於寫底層程式、嵌入式系統或編譯器後端的工程師，xor r, r 至今仍是最安全、最普遍受到硬體優化支援的清零慣用語——繼續用它完全正確，但現在你知道了「為什麼」。
來源：lobste.rs, blog.gslin.org, devblogs.microsoft.com