From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: Use (eval-when-compile 'treesit) to save us from writing declare-function forms Date: Thu, 12 Dec 2024 21:01:35 -0800 Message-ID: <75CFD689-EEC3-4CFE-8F86-E2B18FB0EB6D@gmail.com> References: <2C0B7D3A-6131-4427-BF04-9211981B57DD@gmail.com> <867c8g3o6v.fsf@gnu.org> <0D278D91-4D67-4E0E-869F-6AF0A46678F7@gmail.com> <791c31a1-84ab-4cab-921b-cc8977e980d9@gutov.dev> <86ed2d1jvo.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26612"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , Andrea Corallo , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 13 06:03:01 2024 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 1tLxpM-0006ku-Pd for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Dec 2024 06:03:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLxoK-0006w8-IT; Fri, 13 Dec 2024 00:01:56 -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 1tLxoJ-0006vr-0a for emacs-devel@gnu.org; Fri, 13 Dec 2024 00:01:55 -0500 Original-Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tLxoG-0008Tj-2S; Fri, 13 Dec 2024 00:01:54 -0500 Original-Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-728f337a921so1503998b3a.3; Thu, 12 Dec 2024 21:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734066108; x=1734670908; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VpKPrC/P8iwopoWTDb98omWblsE+C3aV3F20r5QLKm8=; b=lq+vdm8iRLDaRL8vMTPptckjYWrSGoqD9BjKVGCLpN4rB3ptHmlmaE5bcwmm13nu1H q2T7wgnP+PeIffWZYUhPyJibMujjM+EpDRDd1sfbzXv3cccDjyTWESKwL+VY+Ex41CKu OwnOJYjA3glF0fNz0Wme6roPloRidpa06ef0DDDX1lrlMnZ+uaExAkfgjIf/lUrmjGqb PKdLt/u5j4kfnNA0aBX4xzwlGVvtfe/EMITGLsPGPsEV4kdXF4mDoDslHLEbuU2a+Pn7 jyu43RCNCq5lvH1USOb0P9tybENJnEf/NTNsm6XC20ugw/Ik6ydQdIFOROSmtxJqBtpr a2dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734066108; x=1734670908; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VpKPrC/P8iwopoWTDb98omWblsE+C3aV3F20r5QLKm8=; b=IhqEm89l3+dcyO09B/lusN7/3senp80+MPHFGMMrzJ+uM5PbFhHuEouin0pyznjBH9 mXy+HLAu08Th4L3W2koPsNm2TWFD+CTG4ISUoIa/X+P03YQqEritRlwjBLtga4qUcaeP MZrYTQKzTFa0JLeyg5phusbjPPnti+2iiMUrlGHbsuv/AwXg5PgGmTrn3ImI1b9xK+u5 tMnkuN9uY6rBD4Qc1yMg7a1oNwfQTvTTCQoYuUm+8/PBnyjYmGsGx2N7essnhi1e7kGR GkEwbZ+S2z0hjTVOWjKgFmoQklWROBaf8HzmIPDizLLovYfUdNdGpoZbcfI5Heqsu5vC WUbg== X-Forwarded-Encrypted: i=1; AJvYcCUz5UcU4PecZHRRdsoc6yqjanH/LsWwlXQOjYmfhEi1z+uDr5RQ0OHH4mNHkLZaXWp1XR2mBdtlTilISgc=@gnu.org, AJvYcCW6Bz6dzyNG1FTD5UV+sfLA9bnEwXvd69KwlyYI1M5cnby01m02jHWkHy52j+NMSu0B7fpPuDKfsQ==@gnu.org X-Gm-Message-State: AOJu0YxKREIiPR4sj20pgSZXYjVRnAN9gQ50hq/EOUEN1y12WA1ONcEg pIo7fIV/fN31M5ovzE3b5w52AoDEk/w8vyNsEdbsokjyuTik6FoxtG93Vw== X-Gm-Gg: ASbGncvtntHzNUhVT8N71e0WxQMjGYBFqiDAW1XOdfjcKGA+6sWWy2KXypJEwe3kl0a ZObyoNhQd84zAei791J1oE0UThR5Ar6YTgvzae3biAyXwbdpPHC0KKt8trx6V9oTS//eReM27Ei DgmM53XtUNGDuum95nmzkmFgiqylSMv9FTPPlgXbjCQKDJXY8xUvamnI5DKhUfKH0MUgCnhzee7 btLxTMw1ioN/wWkSJInt7AT8kTP0vT6YniWI24JTP++aNbPeyXkgh02HCsc1eakvFhjMvKqtw87 qc96 X-Google-Smtp-Source: AGHT+IHhWDcTLwzYLmgzB+BtYC3OnHdKNEfxb64yF5ovCZbFsPcoLbnJjeLZd1+w7Toa+YnwmGitXg== X-Received: by 2002:a05:6a00:e06:b0:725:f359:4656 with SMTP id d2e1a72fcca58-7290c264e3fmr1869429b3a.18.1734066107698; Thu, 12 Dec 2024 21:01:47 -0800 (PST) Original-Received: from smtpclient.apple ([2601:646:8f81:6120:1591:1a19:416c:1925]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-725e7fa00c2sm8736676b3a.156.2024.12.12.21.01.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2024 21:01:47 -0800 (PST) In-Reply-To: <86ed2d1jvo.fsf@gnu.org> X-Mailer: Apple Mail (2.3776.700.51) Received-SPF: pass client-ip=2607:f8b0:4864:20::435; envelope-from=casouri@gmail.com; helo=mail-pf1-x435.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326448 Archived-At: > On Dec 11, 2024, at 10:43=E2=80=AFPM, Eli Zaretskii = wrote: >=20 >> From: Yuan Fu >> Date: Wed, 11 Dec 2024 22:05:56 -0800 >> Cc: Andrea Corallo , >> Eli Zaretskii , >> emacs-devel@gnu.org >>=20 >>=20 >>=20 >>> On Dec 11, 2024, at 4:23=E2=80=AFPM, Dmitry Gutov = wrote: >>>=20 >>> On 12/12/2024 01:38, Andrea Corallo wrote: >>>> The suggestion of having the C functions defined to nops when >>>> HAVE_TREE_SITTER is not defined is cleaner in principle, but I = think >>>> there are two downsides: >>>> - We don't tipically do it this way, so it would be an exception >>>=20 >>> We also don't typically require a caller to have a = 'declare-function' for every function they use from a package that they = (require ...) already. >>>=20 >>>> - Also we should do it for all the functions in treesit.c, = otherwise we >>>> don't solve the original problem of introducing warnings by = mistake on >>>> non treesit builds. >>>=20 >>> Sure. All non-static ones anyway. >>=20 >> I tried to define all the C functions and it=E2=80=99s not easy to = do: doing it in C seems pretty tedious, we=E2=80=99d need DEFUN form and = defsubr for each function (is there a easier way?). If done in lisp, we = need to do it in a separate file and _load_ it before compiling = treesit.el and any other package that uses tree-sitter. I=E2=80=99m not = familiar with Emacs=E2=80=99s build process so I don=E2=80=99t know how = and where to add such a file and make Emacs load it on startup. >>=20 >> Can someone enlighten me on how to define these functions in either C = or lisp? >>=20 >> I think defining them as no-op for Emacs w/o tree-sitter is a good = move, because otherwise if some user compiles an Emacs w/o tree-sitter = and compiles a bunch of packages, and one of the package happens to be = based on tree-sitter, they=E2=80=99ll see a bunch of warnings unless the = package author added declare-function forms or the proposed macro. = It=E2=80=99s better to have tree-sitter functions always defined and = save everybody some hassle. >=20 > FWIW, I'd rather we didn't go this way, for the reasons Andrea > explained (and I agreed). Inventing some new technique or tricks just > for this one case, when we don't do anything like that in any other > similar case, doesn't sound like a good idea, because it would mean > one more subtle protocol to support in Emacs development. It gets in > the way while reviewing patches, for example, because it is not easy > to remember when special conventions must be observed. E.g., should > someone come up with a new DEFUN in treesit.c, someone should remember > that a no-op function by the same name should be defined at the same > time. Or we'd need to #ifdef out the body of each DEFUN, which makes > the code harder to read. >=20 > Can we find some other way of making this easier, without defining > no-op functions in treesit.c? Cool. I don=E2=80=99t want to waste more of everybody=E2=80=99s time on = this, so I pushed the original patch (sans eval-when-compile) which I = believe everybody is ok with. Yuan=