處理 embedded plugin 和 standalone plugin 打架的問題

[pi314]

[pi314]

仔細想了想，這個功能真的有需要嗎？

至少目前我想不到有什麼 embedded plugin 只能附著在其中一個輸入模式下的

[pi314]

修改了方向，從 standalone 的角度看可能比較合適

[pi314]

#26 (讓 standalone plugin 決定送字的 key) 和這個可能有關

[pi314]

想了很多天，
在流程上，embedded plugin 是優先執行，
所以要是 embedded plugin 註冊了太多的 trigger key，
或是某個 standalone plugin 本身就需要很多的 trigger key（例如注音輸入）
embedded plugin 就有可能擋在 standalone plugin 前面，使後者無法正常使用。

現在有兩個解決方向，一個是實作這個 issue 的功能，
讓 standalone 有權力禁止 embedded plugin 擋在它前面。
但這個方式的問題是 standalone plugin 根本不會知道有哪些 embedded plugin 可以用，
也不可能列出所有允許或不允許的 embedded plugins，只能全開或全擋。

另一個是改變流程，讓 standalone plugin 優先判斷，
沒有結果才丟給 embedded plugin。

現在覺得把 embedded plugin 往後移比較好，不過還要再想一下會不會有問題。

[pi314]

如果 embedded plugin 調到 standalone plugin 的後面，就換成它被擋住了。
但這樣的狀況就交給 standalone plugin 去考慮吧。

如果確定要這樣修改的話，要記得修改 doc #37

[pi314]

測試了一下，狀況不太好，embedded plugin 被擋住的狀況太嚴重了。
是可以解決，但方法是 standalone plugin 的 pattern 設為 .*，再由 handler 重新 match。
這樣完全不對，沒有 decouple 的效果。

這個修改先暫緩，需要再想想該怎麼處理。

整理一下目前的想法：

• 我覺得 embedded plugin 還是有存在的必要，因為有些好用的功能太小，真的不適合做成 standalone plugin。
• 但兩者的順序不管怎麼擺都會打架。
• 如果把所有 embedded plugin 收集起來，成為一個輸入模式呢？
• 這個輸入模式和 standalone plugin 對等，就不會打架了。
• 可以由某個特定 (configurable) 的 key trigger，只搜尋 embedded plugin。
  • 要不要允許這個 key 和 standalone plugin trigger key 重覆需要再考慮。