From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter integration on feature/tree-sitter Date: Fri, 13 May 2022 12:52:17 +0200 Message-ID: <87lev5puvy.fsf@thornhill.no> References: <87y1zabmbt.fsf@gmail.com> <5F186EBD-CD21-422B-8B4F-0D5424173334@gmail.com> <875ymdwf76.fsf@gmail.com> <011DA1A3-0FA8-4449-878A-FD6B336B0F1B@gmail.com> <8735hhw75p.fsf@gmail.com> <83czgks4ss.fsf@gnu.org> <87wnesuw63.fsf@gmail.com> <83pmkkqhft.fsf@gnu.org> <87tu9wukbt.fsf@gmail.com> <83ee10qbk7.fsf@gnu.org> <8F6A43D1-D1EA-4602-A245-627DB7960FC2@gmail.com> <838rr7qqhw.fsf@gnu.org> <87sfpekf6t.fsf@gmail.com> <838rr6pwjt.fsf@gnu.org> <87pmkik7x6.fsf@gmail.com> <83wneqoej5.fsf@gnu.org> <87mtfmk4oi.fsf@gmail.com> <83ee0yndor.fsf@gnu.org> <87r14xq2oc.fsf@thornhill.no> <835ym9oh0u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24929"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yoavm448@gmail.com, casouri@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 13 12:53:58 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npSvk-0006In-QC for ged-emacs-devel@m.gmane-mx.org; Fri, 13 May 2022 12:53:57 +0200 Original-Received: from localhost ([::1]:49992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1npSvj-0006IU-NB for ged-emacs-devel@m.gmane-mx.org; Fri, 13 May 2022 06:53:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npSuH-0004zE-0S for emacs-devel@gnu.org; Fri, 13 May 2022 06:52:25 -0400 Original-Received: from out0.migadu.com ([2001:41d0:2:267::]:52058) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1npSuE-0007Y4-0L; Fri, 13 May 2022 06:52:24 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1652439138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4ElyuBzZjeqQfS09M9efZa2UPglfumLbzPFzQesp2CU=; b=AYKhLqu8JUQxYgD+D7kOKegPLUI9RmItflGDlJWifrobAG1NPi6xzt4ZfcTmUD4nI+bjm5 wRHLR+wzHbcrLmzKopO4xjTkdYo6/01BE1v4PajOXoI7/u6nQIspBKoycxNT8KkGMpDvez Rp33lvcj1EL6mqY2eI/NSNSxjrZIBrjoY1Vk7bgGOrakl5l4dZGU89MhiMQsaerYqK392i qYBHXIIyP8erulBDtmP4Z8pBDf4FeaNVkOVtg+fG3HoGfjEkE7ZfY2aQ1q5Mir6o/PnybM 07NqfAukNphvfdDzgRQ8eSaF4S0N8Th05QN31ytX0Z/WeXnQ095kP0C9Lsg7MA== In-Reply-To: <835ym9oh0u.fsf@gnu.org> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: thornhill.no Received-SPF: pass client-ip=2001:41d0:2:267::; envelope-from=theo@thornhill.no; helo=out0.migadu.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:289724 Archived-At: Eli Zaretskii writes: >> From: Theodor Thornhill >> Cc: casouri@gmail.com, emacs-devel@gnu.org >> Date: Fri, 13 May 2022 10:04:03 +0200 >> >> > Is it true that there's just one query for each PL mode, and it is >> > fixed (doesn't change) and doesn't depend on the buffer contents in >> > any way? If that is true, the major mode could compile the query >> > whenever it is initialized, and then reuse it in every buffer that is >> > under that major mode. >> > >> >> Yes, for indentation and font locking, this is correct. I'd think that >> it'll be enough to compile on mode init, and just reuse it. For some >> hypothetical other uses, such as searching and replacing, we would need >> to be more dynamic, but that won't have the performance issues that font >> locking typically has. > > Right. > >> Why not use the same idea as the `eglot-managed-mode`, where if the >> file fulfills some predicate, we choose to treat them all as equals. >> Thus we only need to compile/read/use the queries once, and can >> simply lookup what we need. > > We can do something like that if needed. But I don't necessarily see > the need yet. When will we need this, if a major mode compiles the > query once when it is first turned on in some buffer? > Thinking more about that, I don't think we do need it, considering it will run as a major mode. I guess it may be interesting should we want to supply tree sitter functionality as minor modes. Let's say that some major mode author doesn't want to integrate with tree sitter, and won't accept such a patch. Then we could still allow overriding font locking of that mode given the proper means to do so. Another case is for minor modes such as paredit and the likes. It could support advanced editing facilities without being part of the main tree sitter major mode integration. Then it would make sense to have a tree-sitter-minor mode thing. But this is all just ideas from the top of my head, and not necessarily anything worth considering for the first implementation of tree sitter. >> > There isn't any (IIUC what you are asking). Fontification is a >> > feature of interactive sessions, and is basically meaningless without >> > normal redisplay. >> > >> >> An ok benchmark would be using C-n rather than C-v, because that seems >> to trigger more performance issues in my daily use. > > We should benchmark both, because both are important. Agreed