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: Average-user-facing interface for tree-sitter Date: Sun, 23 Oct 2022 06:59:42 +0200 Message-ID: <160EF6FA-60E5-45E1-9419-27F5ECA08E6A@thornhill.no> References: <8BAAB6CC-C8BA-4255-9E60-8963A828BE31@gmail.com> Mime-Version: 1.0 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="20842"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-devel To: Fu Yuan , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 06:44:56 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 1ompKY-00058w-Sp for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 06:44:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omkXl-0004YN-1A for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Oct 2022 19:38:13 -0400 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 1omT5p-0007j0-Bq for emacs-devel@gnu.org; Sun, 23 Oct 2022 01:00:13 -0400 Original-Received: from out0.migadu.com ([94.23.1.103]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omT5l-0000lt-1Y for emacs-devel@gnu.org; Sun, 23 Oct 2022 01:00:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1666501203; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rdS4w3v0aVr/G0k1LA2NGFXasbwTMUcSnVjl53IS/cI=; b=Bj0FAiDo+mEx4kJn6Tg5P577ow8/W1GoDQ+b/oyPa+MpchyrztLk3rtykYPDKb+IfMh6Xf VvYyZBprGn0+0uEBP7QywpDgO9UGhKUNwvLH9bLyaiDgtWl9xU9CXgGgrY0mjtfptCBmC7 GrsCXTUis2vwKEQlkt3ytWK2fwdhjEAwmAKZFIV3+0pM4HTvyEelZB9qb+oeAh6JfnOSG5 Mi1+qlShvUxM+FFQ4w74HR2f/MvWIOEmM2fi5btA477eFlzZKgdKEZx0kMRWcjMYO0/Tao Fxo/yQqz5M6PL1eyw1Ed19tgFENXYajDQ8s27yBhq724l46L2j95u9OKcFNs9A== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-Reply-To: <8BAAB6CC-C8BA-4255-9E60-8963A828BE31@gmail.com> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=94.23.1.103; 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_PASS=-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" Xref: news.gmane.io gmane.emacs.devel:298315 Archived-At: On 23 October 2022 03:59:35 CEST, Fu Yuan wrote: > > >> =EF=BB=BF >>>=20 >>>>> Yeah=2E Shouldn't it be possible to just have a global var instead = of a >>>>> mode? That way we can just look for that variable when enabling the >>>>> mode, and avoid calling anything other than what we want=2E At leas= t for >>>>> the foreseeable future, enabling these per mode in the init file >>>>> shouldn't really be too much of a problem, IMO=2E When more users >>>>> actually get to try this we can get a feel for how the init should b= est >>>>> be handled=2E >>>>>=20 >>>>> To me the '*-use-tree-siter' defcustoms was beautiful :) >>>>=20 >>>> Back to centralized variable, perhaps? >>>=20 >>> I=E2=80=99ve thought really hard but didn=E2=80=99t come up with any b= rilliant ideas, so I=E2=80=99m >>> going with centralized variable=2E Now, should I throw away recent com= mits and >>> create a new branch so we don=E2=80=99t have so many changes back and = forth on js=2Eel >>> and python=2Eel? Plus feature/tree-sitter wouldn=E2=80=99t be used for= long anyway >>> since it=E2=80=99s merging into master soon=2E >>=20 >> I'd wait a bit more to see if some other ideas come up first=2E > >Here=E2=80=99s my thought (that didn=E2=80=99t go anywhere): since major = modes sets a plethora of local hooks and variables, only the major mode its= elf knows how to reverse them=2E The cleanest way is probably to clear all = the local variables and hooks and re-run the major mode setup, which sugges= ts we should let major mode branch on whether to enable tree-sitter during = initialization=2E I wonder if minor modes can somehow work with this model? Yeah, that's what I was thinking too=2E We can just separate the inits int= o its own function and use a coed=2E Adding other variants will then be tri= vial=2E=20 > >It would be also nice to leave room for inclusion of other =E2=80=9Cbacke= nds=E2=80=9D besides elisp and tree-sitter in the future=2E > >Yuan Theo