unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Yuan Fu <casouri@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: 75198@debbugs.gnu.org
Subject: bug#75198: 31.0.50; [treesitter] peculiar error
Date: Sat, 4 Jan 2025 11:22:54 -0800	[thread overview]
Message-ID: <E151C5AD-B910-43EC-B580-1F352111D667@gmail.com> (raw)
In-Reply-To: <87pll2mq7c.fsf@mail.linkov.net>



> On Jan 4, 2025, at 9:43 AM, Juri Linkov <juri@linkov.net> wrote:
> 
>>> The problem is that 'treesit-parent-until' raises an error by default.
>>> So needed to copy its implementation where treesit-node-match-p
>>> sets the argument IGNORE-MISSING to t.
>>> 
>>> Or maybe better to add new arg IGNORE-MISSING to treesit-parent-until.
>> 
>> Hmm, I’m not sure. If we go this route, we’d need to add IGNORE-MISSING for
>> every single function that uses treesit-node-match-p.
> 
> Agreed, adding a new arg to all such functions is not the right thing.
> 
> Then maybe better to define the preferred behavior
> by a new dynamically bound variable, e.g.
> (let ((treesit-raise-error t)) (treesit-parent-until ... pred))
> 
>> It’s better for these functions to check whether the definition of the
>> thing they’re going to use exists or not, before calling
>> treesit-node-match-p; alternatively, if they know they don’t care,
>> they can pass t to IGNORE-MISSING.
> 
> Not sure how much this will degrade the performance of
> every function that uses treesit-node-match-p.

It should be negligible, plus if a function wants to use a thing, it’s TRT to first check if the thing exists, right? Otherwise they can just pass IGNORE-MISSING.

There might be cases where the function can’t know whether they can ignore missing. In that case they can expose the IGNORE-MISSING parameter in their signature.

Treesit-raise-error-p could make sense, but it’s a rather significant commitment and I don’t see any strong argument for it as for now. 

Yuan




  reply	other threads:[~2025-01-04 19:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-30 12:27 bug#75198: 31.0.50; [treesitter] peculiar error German Pacenza
2024-12-30 13:47 ` Andreas Kurth
2024-12-30 17:54   ` Juri Linkov
2025-01-04  8:26     ` Yuan Fu
2025-01-04 17:43       ` Juri Linkov
2025-01-04 19:22         ` Yuan Fu [this message]
2025-01-05  7:43           ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E151C5AD-B910-43EC-B580-1F352111D667@gmail.com \
    --to=casouri@gmail.com \
    --cc=75198@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).