ABAP開發環境語法高亮的那些事兒

關於SAP ABAP開發環境，Jerry之前寫過幾篇公眾號文章：

• 那些年我用過的SAP IDE
• 不喜歡SAP GUI？那試試用Eclipse進行ABAP開發吧
• 使用Visual Studio Code編寫和啟用ABAP程式碼

本文從另一個角度出發，單獨聊聊ABAP開發環境裡的語法高亮話題。

俗話說，佛靠金裝，人靠衣裝。我們們程式設計師雖然平日上班都穿千篇一律的職業裝：

程式設計師專用的格子傘：

Jerry衣櫃裡最不缺這種衣服：

但幸好我們的開發環境還是能夠進行各種個性化設定，所以雖然大家都穿著一樣的格子衫，但面對的卻是色彩各異的開發環境。比如SAPGUI的Options選項，給ABAP開發人員提供了種類豐富的ABAP編輯器UI元素風格的自定義設定，諸如背景色，關鍵字高亮顏色，註釋高亮顏色，斷點高亮顏色等等。

我們點了Save按鈕後，這些個性化設定儲存在本地某處。那麼以ABAP編輯器為例，當我們用它來編寫程式碼時，ABAP語言裡的語法元素是如何根據不同的型別，進行對應的顏色高亮顯示呢？

在SAPGUI設定選項裡，進入Traces->Session Traces, 點選Enable按鈕開啟ABAP Editor的trace開關，回到ABAP編輯器，隨便做一些操作，比如加一段註釋，幾個空格，啟用程式碼之類。

然後開啟生成的trace檔案：
C:\Users<user name>\AppData\Local\SAP\SAP GUI\Traces\sapfewdll_01_0001_00_4272_2800.trc

能看到大段大段的CStyleCache::OnLinesChanged和CAbapFgLexer::InternalLexer這種C++裡類的方法呼叫。

• 189行：InvalidateLineStyle - 準備重繪ABAP程式碼第43883行的語法高亮
• 190~191行：FindBeginOfStatement + FindEndOfStatement：找到這一行ABAP語句的起始和結束位置。
• 193行：synchronous syntactical analysis started - 開始同步模式的語法分析
• 195行：呼叫C++實現的編譯器方法m_parser->run, 來完成ABAP語句的語法解析，總共花了89微秒。
• 196行：分析結束。
• 197行：根據編譯器的分析結果，呼叫ISyncStyleCache::SetStylesSync進行對應元素的語法高亮顯示。

從trace檔案不難看出，這個ABAP語句語法分析和語法高亮渲染的同步過程會逐行處理語句，大家平時幾乎感覺不到任何時延，是因為編輯的ABAP程式碼行數較少。

當Jerry在本地編輯ABAP git這個開源專案時，因為report原始碼有將近五萬行，所以當修改完程式碼啟用之後，會感覺到長達好幾秒鐘的時延，在這幾秒鐘內，SAPGUI裡的C++實現的編譯器在忙碌地進行ABAP語句解析和語法高亮的工作。 在這些工作未完成之間，ABAP編輯器裡將不會有語法高亮效果顯示：

如果不考慮cache的情況，在Jerry手上用的Thinkpad P50電腦上，假設按每行解析花費89微秒來計算，ABAP Git的語法高亮大概會消耗4秒鐘的時間。

說完了SAPGUI，再來看看其他ABAP開發環境。雖然SAP WebIDE還不能做ABAP開發，但是在S/4HANA裡，我們也能在瀏覽器裡用ABAP編寫Custom Logic了，並且支援語法高亮。

你也許會問，ABAP的語法高亮是如何在瀏覽器裡顯示的？自己動手，豐衣足食。

下面跟Jerry一起來透過除錯的方式，自己找到問題的答案。

(1) 在瀏覽器裡敲個ABAP的關鍵字，比如data。發現被高亮顯示了。透過Chrome開發工具發現高亮是透過一個叫ace_keyword的css類實現的。

在Chrome開發工具裡以關鍵字".ace_keyword"搜尋: 發現這個css類是硬編碼在theme-sap-cumulus.js裡的。

(2) 現在需要找到瀏覽器裡進行ABAP程式碼編輯的編輯器的實現。在Chrome開發工具裡Network tab裡輸入“.xml”作為過濾條件，於是找到編輯器的Fiori實現: Editor.view.xml

具體的編輯器是實現在名稱空間reuse的ABAPWrapper標籤裡。

根據這個名稱空間找到實現ABAP編輯器的UI5應用，如下圖: nw_aps_ext_lib.

開啟ABAPWrapper-dbg.js, 在第68行設定斷點。這個函式負責從ABAP後臺取PAD檔案，該檔案和語法高亮有關。

重新整理ABAP編輯器頁面，斷點觸發，在偵錯程式裡觀察PAD檔案的內容:

所有的ABAP關鍵字都列在該PAD檔案裡，這樣UI5就知道編輯器裡哪些字串應該做高亮顯示。

(3) 最後一個問題就是，比如當我敲了一個ABAP關鍵字"new"之後，UI5應用具體哪行程式碼將對應的css類加到這個字串對應的DOM節點上？

如下圖，一旦我敲了一個字元w之後，字串new作為一個關鍵字需要被高亮：

具體邏輯如下圖：一旦敲入字元"w"後，onInput作為事件處理函式觸發:

函式$renderLine負責生成對應的HTML原始碼。輸入字元"new"被傳入函式getLineTokens來計算該字串是關鍵字還是普通變數。

在檔案AceRndTokenizer.js裡, ABAP解析器按照我們期望的將“new”解析成關鍵字，因為解析器擁有PAD檔案的引用，因此它知道哪些字串是關鍵字，哪些是普通變數。

(4) DOM節點的原始碼在此處生成，"ace"和“keyword"做連線操作，生成最後我們在Chrome開發工具裡看到的完整css類ace_keyword.

謎底就這樣揭曉了。

至於其他工具，比如Visual Studio Code，Sublime Text之類，嚴格意義上講不能算作ABAP的開發環境，只能看成是ABAP程式碼的檢視工具，其ABAP語法高亮的實現，我們們下次再聊，感謝閱讀。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":