deno-bridge

Emacs-general
40

你最后说的这个问题， 我已经提交补丁 Make sure deno-bridge-exit success even deno process crash. · manateelazycat/deno-bridge@9d6c52f · GitHub 更新了， Deno 挂了， deno-bridge-exit 都可以正常清理。

1 个赞
41

这么牛逼的吗。 对比lisp的性能如何

42

这个 POC 还对不不出性能来，我觉得一些复杂计算 deno 肯定有优势。

43

突然想起来，是不是应该制定一套 Emacs RPC 规范，包括通用部分和括展部分。这样所有同外部进程的通讯都可通过同一套东西来进行，只需要一个 EPC Sever 在 Emacs 里面，其他的通过括展来做。

似乎已经有了，GitHub - kiwanami/emacs-epc: A RPC stack for Emacs Lisp, LSP-Bridge 也用了 EPC。但这只是协议层吧，在这之上应该加上通用的变量和函數，比如 get-emacs-var、ping、eval-in-emacs 等等。

不知道这个 deno-bridge 属不属于这个范畴。

44

EAF/lsp-bridge用的是 epc + sexp 通讯。

deno-bridge 用的是 WebSocket。

其实我觉得 WebSocket 更好一点， 因为各种语言都可以支持， EPC的问题是， 如果 EPC 的作者不支持， 其他语言要支持 EPC, 就要写一套支持 EPC 的 server/client。

RPC 本质是双向通讯， 两种语言都要实现 server/client 。

45

自从 google.cn 挂了以后， youdao和baidu的翻译质量都堪忧， 这段时间我的 insert-translated-name 插件基本就是挂的。

今天基于 deno-bridge 和 puppeteer 写了一个 DeepL 的翻译后端， 基本可以替代原来 Google 翻译的质量。

用 Puppeteer 的优点是， 直接后台跑了一个浏览器来抓取 DeepL 网页的翻译结果， 这样的好处不需要弄DeepL API Key (DeepL key 注册需要信用卡， 还不能用中国的，限制还多） 就能免费的使用其翻译结果。 缺点是，第一次翻译比较耗时。

第一次以后的查询基本上就是秒回的性能， 非常的方便。

相关的实现可以查看：

5 个赞
46

@P233 最新版的 deno-bridge 不需要再设置端口号了， deno-bridge会自动分配 localhost 没用的端口， 避免手动设置以后插件多了冲突。

顺便分享一下Elisp版的函数：

(defun deno-bridge-get-free-port ()
  (save-excursion
    (let* ((process-buffer " *temp*")
           (process (make-network-process
                     :name process-buffer
                     :buffer process-buffer
                     :family 'ipv4
                     :server t
                     :host "127.0.0.1"
                     :service t))
           port)
      (setq port (process-contact process))
      (delete-process process)
      (kill-buffer process-buffer)
      (format "%s" (cadr port)))))
3 个赞
47

感谢大佬，正好明天有时间，可以专心写一写 :blush:

48

最新版 TypeScript 的 unpack 有所调整， 请参考 README demo

1 个赞
49

目前开发完成度在 1/3 左右，跟 elisp 写的 emmet-mode 比有肉眼可见的提速。

fork 了 emmet-mode 了一份，改来改去恼火，现在一方面复用了 emmet 的全部功能，一方面又能按自己的需求随意拓展，很开心😄

1 个赞
50

最新版增加了对 ansi-color 的支持， console.log 打印的时候， Emacs端不再显示乱码。

2 个赞
51

这个插件很有意思，给 Neovim 添加鼠标手势：

52

哈哈哈哈， 欢迎写插件， 但是我完全不用鼠标。

53

:joy: 我太菜了，连基本的快捷键都没掌握呢。

我也不用鼠标好几年了，但是离不开触控板 :sweat_smile:

54

厉害！ zsbd

55

v8 的性能很强悍啊

;; https://www.gnu.org/software/emacs/manual/html_node/elisp/Speed-of-Byte_002dCode.html
(defun silly-loop (n)
  "Return the time, in seconds, to run N iterations of a loop."
  (let ((t1 (float-time)))
    (while (> (setq n (1- n)) 0))
    (- (float-time) t1)))

#[defun]
fn silly_loop(env: &Env, n: i64) -> Result<Value<'_>> {
    let start_time = SystemTime::now();
    let mut i = n;
    while i > 0 {
        i = i - 1;
    }
    let end_time = SystemTime::now();
    let difference = end_time.duration_since(start_time)
            .expect("Clock may have gone backwards");
    env.message(&format!("time: {difference:?}"))
}

function silly_loop(n: int) {
    const start_time = new Date();
    while (n--) {

    }
    return (new Date() - start_time)
}

用 elisp，rust，deno 执行 (silly_loop 50000000) 的时间对比

语言 执行时间
interpreted elisp 2950.89 ms
byte-compiled elisp 544.47 ms
native-compiled elisp 320.82 ms
rust(emacs rust dynamic modules) 67.15 ms
TypeScript(deno-bridge) 43.06 ms
56

是， 基本上是 Elisp 的几十倍。

57

v8对循环会做动态优化，循环的前几次和后面的运行速度会不一样，如果循环内部什么都不做的话，这样的时间没有太大意义。

2 个赞
58

期待一个 killer app 啊

59

是的。还要加上数据交换的开销