From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#61529: 30.0.50; tree-sitter: weird off-by-one error but only in css-ts-mode(?) with `treesit-node-at' Date: Wed, 15 Feb 2023 19:35:26 +0100 Message-ID: <87cz6a7p5d.fsf@thornhill.no> References: <87mt5fjpwu.fsf@masteringemacs.org> <83v8k3avv8.fsf@gnu.org> <87h6vnjath.fsf@masteringemacs.org> Reply-To: Theodor Thornhill Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35381"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 61529@debbugs.gnu.org To: Mickey Petersen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 15 19:36:21 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pSMdh-00090D-0c for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Feb 2023 19:36:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSMdQ-0000VG-Vo; Wed, 15 Feb 2023 13:36:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSMdO-0000Ud-TU for bug-gnu-emacs@gnu.org; Wed, 15 Feb 2023 13:36:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pSMdO-0004Xb-Ip for bug-gnu-emacs@gnu.org; Wed, 15 Feb 2023 13:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pSMdN-0006ut-T1 for bug-gnu-emacs@gnu.org; Wed, 15 Feb 2023 13:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Theodor Thornhill Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Feb 2023 18:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61529 X-GNU-PR-Package: emacs Original-Received: via spool by 61529-submit@debbugs.gnu.org id=B61529.167648613326552 (code B ref 61529); Wed, 15 Feb 2023 18:36:01 +0000 Original-Received: (at 61529) by debbugs.gnu.org; 15 Feb 2023 18:35:33 +0000 Original-Received: from localhost ([127.0.0.1]:33971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSMcv-0006uC-1d for submit@debbugs.gnu.org; Wed, 15 Feb 2023 13:35:33 -0500 Original-Received: from out-230.mta1.migadu.com ([95.215.58.230]:15441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSMcq-0006u1-No for 61529@debbugs.gnu.org; Wed, 15 Feb 2023 13:35:31 -0500 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=1676486127; 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=qMyIkp9Y6x8tWZcMtODXWUEKTC2FnYxsr29KujJBIZc=; b=Esxh64YkDaYEa+yzUxXlwfpxN+ysVdo2++p7mrcVFHmOerNyVD4gH0Ed4VV6zeXu6AGvT2 XBFwFNobgM/WvoWTIokHGiE9GLiCqGq81wXtBaNFbIzgs5xroMpxw/6M5cZ1J9fPA2BYMA AVx0emc4PUrQd3BMUvEqi8cD3K+wkmIx1MgYlnkVeI/n1Oym5aSqdSIdkExk+CJpJ86zUG kEi+9JUQA0W5HS14dntcsB6/5oDi4I/kQrRMkxxAF9mlpaQfO6sQ7SElqVjJmV43c6+I9s qgCtXFO5yl0oYsgIzEjbuiynfwf2/zr+1j69GDKL9/gG5TQYO9Fh6v+vcSl5Jw== In-Reply-To: <87h6vnjath.fsf@masteringemacs.org> (Mickey Petersen's message of "Wed, 15 Feb 2023 13:42:51 +0000") X-Migadu-Flow: FLOW_OUT X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:255762 Archived-At: Mickey Petersen writes: > Eli Zaretskii writes: > >>> From: Mickey Petersen >>> Date: Wed, 15 Feb 2023 08:25:53 +0000 >>> >>> >>> With point at '2', then I'd expect `treesit-node-at' to yield that node. But it does not: >>> >>> (cons (point) (treesit-node-at (point))) >>> >>> => (34 . #) >> >> The value of point is the number of the character which _follows_ >> point, yes? So when the cursor is on '2', point is actually between >> '(' and '2'. Right? What does this mean in terms of the node that >> should be returned by tree-sitter? > > Correct, point is between '(' and '2'. So 34-35 means it occupies > position 34-35 or [34,35). So point is outside the scope of the '(' > single-char anonymous node. > > Or at least it should be: the problem is that it *is* inside it in > this one weird instance and, near as I can find, only in this mode, > and then only in this place, it isn't. I suspect `treesit-node-at' has > a bug. > Hi, Mickey! > Consider: > > a { > background: linear-gradient(210deg, rgba(|255,82,41,1) 0%, rgba(251,165,85,1) 54%, rgba(163,73,73,1) 100%); > } > > Note the new position of point in rgba. `treesit-node-at` with `(point)` now correctly returns > > # > > Move point back one position: > > a { > background: linear-gradient(210deg, rgba|(255,82,41,1) 0%, rgba(251,165,85,1) 54%, rgba(163,73,73,1) 100%); > } > > And now: > > (treesit-node-at (point)) => # > > In start contrast to the original example. So the docstring of treesit-node-at states: "Return the leaf node at position POS. A leaf node is a node that doesn't have any child nodes. The returned node's span covers POS: the node's beginning is before or at POS, and the node's end is at or after POS. If no leaf node's span covers POS (e.g., POS is on whitespace between two leaf nodes), return the first leaf node after POS. If there is no leaf node after POS, return the first leaf node before POS. Return nil if no leaf node can be returned. If NAMED is non-nil, only look for named nodes." Doesn't this describe this behavior? Theo