你刚才是在做类似这样的工作吗？

你好，@lionel-@alexr00,感谢你提出这个问题。确实，我们目前正在讨论使用tree-sitter来执行缩进。目前，我们正试图改进缩进的正则表达式规则并探索这些规则的极限。正如你提到的，大多数情况下，由于缩进代码不了解上下文，所以正则表达式缩进规则表现不佳。这就是为什么tree-sitter可能是一个很好的替代方案。使用tree-sitter的一个问题是，它将计算缩进更加耗时，并且缩进将异步计算(而当前计算是同步的)。这意味着与format-on-type一样，缩进存在延迟。我们将继续团队内部讨论这个功能请求。

使用tree-sitter的一个问题是，它在进行缩进计算时会更加耗费计算资源，并且缩进计算是异步进行的(而当前计算是同步的)。这意味着缩进与格式化类型一样存在延迟。我们将继续团队内部讨论这个功能请求。
有趣的是，我希望TS的增量重解析能够足够快以同步完成所有操作。据我所知，异步性仅限于渲染器进程，不会受到扩展主机减速的影响？希望大多数时候延迟不会引起注意。
我们正在努力改进缩进正则表达式规则并探索这些规则的极限。正如您提到的，正则表达式缩进规则性能不佳的主要原因是缩进代码无法了解上下文。这就是为什么tree-sitter可能是一个很好的替代方案。
在此我想提一下我们的一个重要用例(在#136593中讨论过):由操作符分隔的表达式链，如a && b && c。在语言R中，这些链(通常称为管道)非常常见：

# ggplot2 pipeline
mtcars |>
 ggplot(aes(
   disp,
   drat
 )) +
 geom_point(
   aes(colour = cyl)
 )
# dplyr pipeline
starwars |>
 group_by(species) |>
 summarise(
   n = n(),
   mass = mean(mass, na.rm = TRUE)
 ) |>
 filter(
   n > 1,
   mass > 50
 )

我们目前使用的是OnEnter规则，旨在避免类似楼梯式的缩进效果：

# Unwanted staircase
foo() +
  bar() +
    baz()
# Expected indentation
foo() +
  bar() +
  baz()

然而，这些规则只能真正处理一行代码，当管道元素分布在多行时，它们开始失效：

foo() +
  bar(
    x
  ) +
    baz(
      y
    )

即使我们可以跨越更多行进行匹配，我认为我们也无法完全用正则表达式表达我们需要的一般性规则。
使用nvim tree-sitter查询，我们可以用以下方式简单地表示这种对齐规则：

[
  (binary_operator)
] @indent.begin

这应该适用于具有相同左结合运算符的情况，因为在那种情况下，由于我们是从右侧进行缩进，当前节点的父节点将是运算符链中最顶层的节点。
对于更复杂的情况，如右结合运算符，我们可以使用Emacs的方法来表示缩进：使用匹配器和锚点。首先，以下是上面提到的相同的nvim规则：

((parent-is "binary_operator") parent-bol r-ts-mode-indent-offset)

这匹配二元运算符的子节点并从父节点进行缩进。为了确保我们总是从二元运算符链的最顶层节点进行缩进，我们可以修改如下：

((parent-is "binary_operator") (ancestor-while "binary_operator") r-ts-mode-indent-offset)

这使用了一个锚点，只要类型匹配，就会沿着树向上爬行，并选择最后一个匹配项的起始位置：

(defun ancestor-while (type)
  (lambda (node parent _bol &rest _)
    (while (and parent (string-match-p type (treesit-node-type parent)))
      (setq node parent)
      (setq parent (treesit-node-parent parent)))
    (treesit-node-start node)))

这个例子说明了TS规则如何表达基于正则表达式的方法难以处理的缩进行为。我们需要一个足够灵活的API来表达更复杂的缩进规则，但应该很容易根据需要扩展API以添加其他匹配器和锚点。

你好@lionel- ,感谢分享这些有趣的想法。遗憾的是，到目前为止，我不清楚我们是否会考虑更改缩进API。如果有这个计划，我会告诉你，并考虑你的想法。
关于异步性，我认为树解析将在单独的工作线程中完成。延迟可能很小，因此正如你提到的那样并不明显 - 我们必须测试以确认这一点。