内置 lsp 感觉还蛮快的，还启用了tree-sitter
似乎可以内嵌lua了，扩展了不少残废的vimL。
一直看不懂tree-sitter 有什么用途。是用于语法高亮吗？如果是的话，默认各个major-mode 不就是有高亮的功能了吗？
1 个赞
谗tui表现力
不用正则表达式匹配所以快一些？
高亮的细致，AST来支持的，不是正则表达式匹配。
我一直在用
2 个赞
多谢各位大佬指点，看来有空得试试看了。
PS：tree-sitter 速度确实快很多，我之前在 Windows 上的 Emacs 写C++，总是会卡一下，用开了tree-sitter-hl-mode 很流畅了 
理性讨论 Nvim那边lsp和tree sitter发展要快一些 Tree sitter不仅仅能用于高亮的，有了整个代码的结构之后还能定义text objects，得到上下文等，这些在nvim都有一些插件了，自己写也简单。lsp我对比下来的感觉同样是pyright，nvim要流畅一些，得客观承认。
啥时候 也来个 NeoEmacs。
试了一下，C++的话感觉不如内置CC-MODE的fontlock好。
我之前提过，但还要再说一遍。语法高亮并不是高亮的东西越多就越好，而是看高亮的东西是否帮助我看清重要的东西。Emacs CC-mode的语法高亮比其他任何编辑器和IDE都要好的原因是它遵循非常一致的原则来高亮代码里真正重要的东西。例如，它会用type-face和variable-face高亮变量声明和函数参数，但是引用这些变量的地方却并不高亮，这使我可以一眼看清这些变量的作用域是从哪里开始的，这对C++语言是非常重要的。假如把所有出现这些变量的地方全都高亮了，虽然看起来颜色很丰富，仿佛很细致，但对编程的帮助反而比较差。
2 个赞
这个其实不难解决, 把不想要的或者想改的高亮 remap 下就好了. 不过不想折腾的话原生的高亮确实省事很多.
个人觉得 tree-sitter 的优势其实类似 LSP, 把各种语言的 parsing 拆出来统一处理, 引入它的编辑器就不需要处理这部分问题了, 毕竟一大堆正则写起来挺费劲的, 也不好维护. 以后大家只需要考虑每类 token 的着色方案就成.
对，比如说 Emacs python-mode 高亮不知道哪出了问题，同样的东西部分高亮部分不高亮😂 比如：
很奇怪我这边用 tree-sitter 却会变慢，之前 profile 了一下主要也就是 redisplay_internal (C function)，不知道为啥
Lua 这个还挺有吸引力的, 很久以前放弃 vim 就是因为 vimscript 写起来比较烦, 前一段时间试了下 neovim, 发现已经可以用 Lua 写配置了, 体验提升不少. 不过在 introspection 上面, Emacs 暂时还是更胜一筹.
1 个赞
内嵌Lua好评，alias vi=nvim
这个是在emacs上基础上改，能算neoEmacs? 
我也有同样的感觉，tree-sitter 在c++ 语法高亮的颜色太多，看的有点缭乱。换了tree-sitter还得修改主题，不然变量引用以及数字的颜色和类名称的颜色都是一样的。