即使符號出現，文字也不會晃動的方法

為了編輯清單而移動插入點時，文字會被推向一旁。插入點移開後，文字又會回到原位。

雖然只有一行移動，卻看起來像是整個段落都在晃動。這個微小的差異不斷打斷編輯的節奏。

原因在於標記的寬度。

平常畫面上會顯示圓形的項目符號。但檔案中儲存的是連字號和空格。插入點碰到標記時，必須顯示原始文字，才能直接修改。

問題在於這兩種形狀所占的寬度不同。項目符號是寬度固定的方框，但連字號和空格的寬度會隨字型而異。在 mote 中，這個差距是 4.9 px。每當原始文字顯示出來，後面的文字就會被推移這麼遠。

讓整行移動寬度的差值

我們沒有讓兩者的寬度完全相同，而是抵銷兩者之間的差值。

標記切換成原始文字的瞬間，將整行朝相反方向移動相當於寬度差值的距離。即使符號的形狀改變，內文開始的位置仍保持不變。

不會動到檔案。項目符號是覆蓋繪製在連字號上的裝飾，而補償只會改變畫面上繪製該行的位置。無論插入點進入或離開，儲存的內容都維持原樣。

計算寬度的基準也統一成一個。以前，繪製標記的位置和補償該行的位置各自使用不同的數值。兩個數值之間的微小差異，正是那 4.9 px。

現在兩邊都透過同一個函式取得標記的寬度。因為只有一個基準，所以也不會再出現偏差。

不過，如果左側留白不足，就不會進行補償。因為移動該行後，文字可能會被裁切到視窗外。比起晃動，文字消失是更嚴重的問題。

標題和引用仍會被推移

一開始，我們也把相同的方法套用在標題和引用上。

但標題的 # 和引用的 > 在平常畫面中所占的寬度是 0。若要固定內文，就必須把符號移到左側留白中。

在技術上運作得很好。文字確實不會移動。然而，畫面看起來很陌生。符號獨自浮在留白中的樣子並不自然。

所以我們還原了這項改動。現在，標題和引用的符號顯示出來時，內文會被推向右側。

最後，我們為每種標記選擇了不同的答案。

像項目符號和待辦事項核取方塊這類在畫面上有方框的標記，會固定內文。像標題和引用這類平常寬度為 0 的標記，則會推移內文。

比起一套統一的規則，自然的畫面更重要。

只在確實需要時顯示符號

減少晃動最好的方法，就是減少符號發生變化的時刻本身。

現在，只有當插入點位於符號上方時，項目符號才會顯示為原始文字。插入點越過空格移至內文後，就會立刻恢復成項目符號。修改清單內容時，沒有必要一直看到連字號。

即使該行太長而換到下一行，也會維持對齊。即使標記以原始文字顯示，第二行仍會從第一行內文的下方開始。

我們也修正了點擊被誤判為拖曳的問題。因為在標記切換的瞬間，只要指標稍微晃動，文字就常常會被選取。現在，指標必須移動超過 8 px，才會被判定為拖曳。

用數字而不是眼睛確認

這種差異很難只靠眼睛確認。短暫查看時似乎沒有問題，但使用久了就會讓人覺得畫面很凌亂。

因此，我們建立了會實際啟動應用程式的測試。將插入點移入及移出標記，直接比較內文開始位置的 x 座標。兩個數值必須相同，才能通過測試。

項目符號、待辦事項核取方塊和巢狀清單，全都以相同方式檢查。

只有一個像素的偏差很難被回報成錯誤。因為使用者與其說明是哪個部分移動了，更常只會覺得「不知為什麼看起來很凌亂」。

所以，這類移動應該由數字而不是人來監看。

安靜的畫面並不是什麼事都沒有發生的畫面，而是必要的變化發生在不會讓人覺得礙眼之處的畫面。