我觉得挺好的哦, 支持一把, 我喜欢这种在线 Markdown 的工具, 提两个优化点:
1. 支持使用 github 作为文档存储位置
2. 支持按照 gitbook 的方式把文件组织起来

@ipadpro4k 铁子, 你这招存在一些小小问题, 知乎的登录框跟滚动条有关联, 如果直接 block 掉这个, 没法下拉滚动.

(只能通过 chromium 的 jk 下拉)

(我的一些理解, 错了欢迎指正)

Q: 此时会触发 Go 的 HandOff 机制，将 P1 detach()到其他 M 上吗？

A: 不会, 这个 G 会被打包成 sudog, 绑定在这个 chan 的相关 sudog 队列上, 等到下次有人从这个 chan 里取数据, 就遍历这个 sudog 队列, 找到这个沉睡的 sudog, 把里面的 G 唤醒, 再放到 P 上去运行

lmao 所有带开屏广告的 App 都卸载了

... 然后他们现在给小程序都加开屏广告了

@yazoox 今天沉下心对比了各种条件下的 vim 的响应速度, 有如下结论:

1. MacVim, 以及其他有 GUI 的 vim, 一定是最快的, 缺点也是因为这个 GUI, 没法跟命令行紧密结合

2. 关了输入提示插件 zchee/deoplete-go 以后, 速度明显更快

3. 同一个大的 Go 项目下, 开了 GPU rendering 的 iTerm2 明显比 Terminal.app 更快, 这个推翻我之前的结论
@Kobayashi @dullwit

4. 同等条件下不使用 tmux 会稍微快一点点(tmux 的影响不算很大)

@Kobayashi 谢谢帮助哦, 但我刚刚尝试了 iTerm, 也开了 GPU rendering, 在我的环境下加速效果比较有限, 呃... 还是比不上 MacVim 的速度 :)

@byzf 可以的😂 折腾一圈还是 vscode 香, 我特么现在也有这种感觉, 反正也要搞 GUI, 为啥不直接用 vscode 呢? vscode 内部还集成了 terminal...😂

@nightwitch Thanks♪(･ω･)ﾉ

Thanks♪(･ω･)ﾉ

@limbo0 一些简单常用的命令通过 :! 来做, 比如 :! pwd, 再多的暂时没更好的办法

@Chingim +1 一点不错

@jessun1990 谢谢, 赞同 , 我也觉得是跟终端有关

@dullwit 嗯嗯, 刚在网上搜了一圈, 其中一个造成卡顿的原因, 就是你提到的"render"(界面绘制), 终端需要不停的 render, 才能把 vim 的界面绘制出来, 从这个角度出发, 有 GPU 加速就会快一些. 我在网上看他们说, 其中最大的因素他们说是因为:

> 是因为 vim 进程是一个 tmux fork 出来的进程, fork 出来的 vim 通过 ptty 将信息传递给 tmux, tmux 再传回给 zsh
> 最终得以绘制, 这么多级的传递造成了明显的延迟.

[Reference]( https://superuser.com/questions/657498/why-is-macvim-much-faster-than-vim-in-the-terminal)

但其实我对这种说法存疑, 我打开非 Golang 的项目, 比如一大堆 shell 脚本, 如果真的是 render 造成卡顿, 那么打开 shell 还是 golang 应该都很卡, 但实际上 shell 就比 golang 快很多.

那就还跟 vim-go 的套件有关, 但我的 MacVim 也一个不少的用了 vim-go 套件, 但 MacVim 就是快... 为啥呢... 玄学? Vim 玄学调参?

@tangbao 谢谢哥们我觉得 MacVim 挺好了, 我就是有点搞不太明白为什么 MacVim 能快这么多, 仅仅是因为有了一个 GUI 的原因吗?

舒服了

哈哈, 是不是用的微信官方的小程序组件 ~