在通過各種編輯工具使用各類編程語言進行開發的過程中，我們會被大量噪音分心。

舉個例子

我們為了美觀性，為了代碼格式和對齊，我們會大量的插入/刪除Space、Tab和Enter。

對于一些同層級的操作，我們可能會手工對齊它。

舉一個極端的例子，例如我寫的代碼就是這樣的

這樣的

以及這樣的

為了使這些代碼變得美觀，變得整齊工整，無疑是一件很痛苦的事。

同時，語法節點的輸入也是個帶問題。

對于一顆語法樹，我們需要輸入它的頭部。例如

match

以及我們需要輸入它的詞法界限來分割它的塊部分，例如

with | 和 ->

——而這是完全沒有必要的

據直覺性的非客觀的不完全統計，在我們寫代碼的時候30%的部分寫的就是這些東西（x

我們完全可以在我們輸入語法樹的頭部時，就讓編輯器幫你弄出整個塊

我們能輸入錯誤的源代碼

這一點我是覺得是最不可思議的。

同志們，已經9102年了，我們用的代碼編輯器居然還能讓我們輸入能讓編輯器報錯的代碼。

Q: 所以，我們需要什么？

A: 所以，我們需要一個高度語言特化的AST編輯器——也就是結構化編輯。它應該最大程度的照顧用戶體驗——也就是以人為本。

注意：它不是圖形化的編輯器，也不是像UE4藍圖那樣的東西。

以及，一些有趣的特性

一旦我們用上了AST編輯，那么我們就可以做一些很好玩的東西了

由于編輯器的操作對象是AST，因此我們就能很輕松的指定由編輯器渲染出的代碼樣式——通過寫插件和編輯樣式文件的方式。

符號查找和定位是低開銷的：對于傳統的編程語言而言，符號查找的開銷無疑是較高的。首先我們需要從源碼中構建出AST，然后我們需要維護一個AST到源碼的映射表——在這個過程中，一旦能構建出AST的Token序列被破壞，那么就我們沒法從源碼中得到任何可用的信息了，我們就只能猜，猜到哪個算哪個。（同時我們能夠避免寫編輯器的String數據結構（比如坨坨桌子（逃

降低Parser實現難度：對于這一點，大錘予以了反駁，他認為合格的編譯器應該獨立處理所有的語法問題。我倒是不這么覺得，首先在任何情況下，讀純ast表達式（包括且不限于json、xml）應該是成本最低的方式了。

舉個小眾的例子：眾所周知，某些語言中提供了自定義運算符和控制流的語法。（點名批評Haskell和F#）而為了實現這種功能，我們在實現Parser的時候會用上很復雜的算法和操作。

我認為這是一種很不干凈的行為，我們完全可以把這部分功能（甚至一部分宏的作用）交給編輯器前端去做。

最大程度上防止用戶寫出有問題的代碼：

這一部分我覺得是結構化編輯最有價值的部分。

舉個例子

我們使用Pigeon（目前還不存在的）語言時，我們輸入了一個表達式

1 + a

——在正常情況下是這樣的

但是，如果我們沒有定義a呢？我們沒有在任何作用域中定義這個a呢？或者說，這個a的類型和(+)這個函數不匹配呢？

我們的編輯器會對它標記一個紅色下劃線？不對，此時這個a是寫不出來的。我們可以在intellcode的提示中直接進入重構引導。

從這一步我們就可以看出來了。整個的代碼編輯過程應該是很流暢的。代碼編輯器每時每刻都在和用戶強交互。

必要性？

看到這里有人會問啦：那么這些東西和我們現在用的編輯器有什么本質的區別嗎？

從使用者的角度來看，兩者都能提供同樣的功能。但結構化編輯器會帶來更整體而非是零碎的體驗。

未來的問題

當然，截止目前，結構化編輯器的構思還有很多問題。例如怎么選擇和操作ast，例如快捷鍵該怎么設置，會不會讓開發者更快患上腱鞘炎（逃）。諸如此類的問題。

但我們仍然選擇相信下一代編輯器，能帶來更好的開發體驗，能夠真正做到以人為本。

總結

以上是生活随笔為你收集整理的c++源码矢量图形编辑器_下一代代码编辑器的设想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。