一個更好的視頻碼頭
之前,??我在寫??? 有關(guān) ??embark?? 的內(nèi)容,我的第一設(shè)備為啟動遠(yuǎn)程視頻流設(shè)計了一個新的 embark。embark 的作者 Omar Antolín Camarena 不僅閱讀了這篇內(nèi)容,還點評了一下我認(rèn)為值得跟進(jìn)的一些重大改進(jìn)。
首先,你應(yīng)該記得我們曾定義過一個檢測視頻 URL 的函數(shù):
當(dāng)我們得到了一個非空的 ??url?
? 值,即便它不是一個視頻鏈接,但它仍然是一個確切的 URL,并且 embark 已有了一個 ??url?
? 類別,所以我們可以借助默認(rèn)的 URL 尋檢器存儲一個新的句法分析,語句如下:
這里有一個潛在的缺點就是:我們重寫了 embark 的尋檢器,??embark-target-url-at-point?
?,所以我們可能更愿意保留后者。
實際上多虧了 embark 的 目標(biāo)轉(zhuǎn)換器 我們才能做成。我們可以在 ??embark-transformers-alist?
? 中添加任意一個函數(shù),應(yīng)用于任何一個給定類別的目標(biāo),而 embark 會將其轉(zhuǎn)換后的值應(yīng)用于它的操作中。Omar 很貼切地把這個過程稱為“目標(biāo)的精化”;我們具體做法如下:
通過這種策略,我們就不再需要 ??jao-video-finder?
? 了,而且從概念上來說,我們的 ??video-url?
? 應(yīng)該被定義為一個精化操作而并非是一個目標(biāo) [腳注 1]。Omar 的第二個提議也與這個概念相契合:想必我們都希望所有關(guān)于 ??url?
? 和我們的 ??video-url?
? 的操作都是可用的,不是嗎? 唔,這就是為什么我們用來定義行為的 ??embark-define-keymap?
? 的宏可以通過使用關(guān)鍵字 [腳注 2] ??:parent?
? 繼承其他鍵映射中已經(jīng)定義的所有操作的原因:
這種繼承鍵映射的功能并非是 embark 的附屬功能:vanilla Emacs 鍵映射通過標(biāo)準(zhǔn)函數(shù) ??set-keymap-parent?
? 已經(jīng)搞定它了。你可以完全不用 ??embark-define-keymap?
? 來定義 ??jao-video-url-map?
?,工作原理是一樣的。
這樣,我們的代碼就能夠更短,特征更多:謝謝你,Omar!
腳注 1:在某些情況下,保留 jao-video-finder 是有意義的,即,如果我們想要改變檢測
URL 的功能的話。例如,我在使用 emacs-w3m 的時候,經(jīng)常有一個 URL
作為文本屬性儲存了起來(實際文本是個鏈接文本)。要通過那里檢索 URL,就需要調(diào)用 ??w3m-anchor?
?,而用 ??embark-target-url-at-point?
? 就會錯過它。對于這種情況,我最終編寫(并使用)??jao-video-finder?
? 將其通過下文定義:
另一種達(dá)成同件事情的方式(再次向 Omar 致敬)便是為 w3m 的錨點放置一個特定的巡檢器(且繼續(xù)使用 video-url 的轉(zhuǎn)換器):
這種方法更加模塊化,并且取決于你們的喜好,且更加巧妙。這些功能都很小巧并且兩種方法之間并沒有太大的差別,但是如果其中某一種繼續(xù)加入更多尋檢器的話,前一種方法用起來來反而會讓一切變得更糟。
腳注 2:在我最開始的例子中,我在視頻地圖中還添加了 ??browse-url?
? 和 ??browse-url-firefox?
?。前一個已不再重要,因為它已經(jīng)在 ??embark-url-map?
? 中出現(xiàn)過了,如果我們想讓 ??browse-url-firefox?
? 對 所有 的 URLs 可用,我們可以將其加入到 ??embark-url-map?
? (謹(jǐn)記,embark 的鍵映射只是 Emacs 的鍵映射)。這是另一種擴(kuò)展 embark 的簡便方法。
(題圖:MJ:emacs video geek wallpaper dark plain background Illustration)