From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Make all tree-sitter modes optional Date: Mon, 16 Jan 2023 15:06:15 +0200 Message-ID: References: <84973.1672843723@hassadar.pretzelnet.org> <83wn62xi3k.fsf@gnu.org> <83o7rexe2n.fsf@gnu.org> <83h6x5xym7.fsf@gnu.org> <83h6wr6gmz.fsf@gnu.org> <831qnu64la.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32768"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 16 14:07:10 2023 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 1pHPCf-0008JH-F3 for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Jan 2023 14:07:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHPBy-0006Fs-E6; Mon, 16 Jan 2023 08:06:26 -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 1pHPBw-0006Fj-Mp for emacs-devel@gnu.org; Mon, 16 Jan 2023 08:06:24 -0500 Original-Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHPBu-0003Ni-7S; Mon, 16 Jan 2023 08:06:24 -0500 Original-Received: by mail-ej1-x629.google.com with SMTP id vw16so4813808ejc.12; Mon, 16 Jan 2023 05:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=p/NTedEvh0ahp7VefTIS3twdC72NyzvVrEK8wLknOFg=; b=PJlJnbj4WIaUJ02DejXxOYu4K5uiI73n38za0qLE5Ps3OYgHUUkNCoJEmaP0nCs9E3 tan8lZA1yBTztv7k0azGv5xPgaDRWR97FBqgfV+6lPmbq+4msvbakw2Y95r0GY5Bb05M An1/g5XYa9N7gafit0sPDAtnymc3LPuBU/xEuA4s0lyZVocuy8Jmc2+5z87XPNMuK2Fq ZFe9/O/tiYIDbefkZmX3rL4Se0ZcXBlk0QAwfORumGT2ATVmf3xWGa6Wg7/tVT/A19ue ShVOkM+UFuZUJ8E2LUePPa+2W8p93oPhC+t/Rhlp2Szu0s8YSarLh9+zz/DX01g0PgyK wOvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=p/NTedEvh0ahp7VefTIS3twdC72NyzvVrEK8wLknOFg=; b=c79JjBVJOlgw/eVuvRveSDcL+1G55b6PJ8kIfdkFqJBLqu1jWd4kI5Qhhf1gg0Gpd2 rRqWSj3f7ACJTeqBkjohzCf8KFkSCXT4VrBbVewQK2L/5Mlx862iOMueAAARiAo7K43U 0CbZH8eQ9dkr6kqr3PrCOvZBAFJ9M4C/lyhRleg0Sy3jKNUbyn/lHYAtWQO1CbLW5ouT B0DtCwrHyipeBatrOA9lkyR4O9EKSKTXFwmM2Nw4NCXP0Bk+tMz+SHDDlopPzgiuj+xU J9crHf/FvyodTSwqtllu7P+CsfAcQlJueyVNLzJqd8T+woV6Ha+xGFtP4SRpvmlbscnY Jv2Q== X-Gm-Message-State: AFqh2krToJV1iXJQFn00RkwzyTf9xcLrywdUmkbfC0Q8jGAjW4o+3G9D I4bgwmaYQH8QbYYNSYJWX1Vb6oycZsg= X-Google-Smtp-Source: AMrXdXtP+kklRr2JSC2C6E1NR2PA6kia9mCrQrJaWHxxJbt9r2TegcpsfQq1l7i+1nr0RP1VQrk3kQ== X-Received: by 2002:a17:906:7f95:b0:86e:f88:c098 with SMTP id f21-20020a1709067f9500b0086e0f88c098mr7265856ejr.70.1673874380262; Mon, 16 Jan 2023 05:06:20 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id kv23-20020a17090778d700b008699bacc03csm4361221ejc.14.2023.01.16.05.06.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Jan 2023 05:06:19 -0800 (PST) Content-Language: en-US In-Reply-To: <831qnu64la.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=raaahh@gmail.com; helo=mail-ej1-x629.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.097, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:302452 Archived-At: On 16/01/2023 14:34, Eli Zaretskii wrote: >> Date: Mon, 16 Jan 2023 01:39:18 +0200 >> Cc: emacs-devel@gnu.org >> From: Dmitry Gutov >> >> On 15/01/2023 16:01, Eli Zaretskii wrote: >>> You will >>> see that where possible, just loading a TS mode modifies >>> auto-mode-alist if the tree-sitter support for that mode is available, >>> whereas for other modes auto-mode-alist is modified only when the mode >>> is actually turned on successfully for the first time. This is >>> because some of the TS modes have their own *.el files, whereas others >>> share a .el file with other modes, and so loading that file doesn't >>> necessarily means the user wants to use the tree-sitter based mode. >> >> If we *are* going to do this (make all ts mode strictly optional), I >> don't think either of this is a good idea: for a given foo-ts-mode, the >> user might already have an auto-mode-alist entry configured with another >> mode (third-party or not), and they will likely 'M-x foo-ts-mode' to try >> how well it works (or doesn't). >> >> Having auto-mode-alist modified automatically can come as a surprise >> either way. >> >> Note the this is different to having the auto-mode-alist entries set up >> from the outset, because the user's alterations override those. >> >> We can drop the auto-mode-alist alterations from ts modes altogether, to >> bring them back when we do decide to enable them by default. > > Like I said: this is not ideal. So I'm not surprised that whatever we > do, there can be usage scenarios where what we do will annoy someone. > > That said: > > . The proposed patch made many changes of auto-mode-alist > conditional where they previously were _un_conditional. It also added some where there were none. > I submit > that this is less annoyance in the important use case where the > tree-sitter or the grammar library is not available. There are > indications that this situation will be frequent enough when Emacs > 29.1 hits the street. Like I said, either making them unconditional, or removing them, would lead to better, more predictable behavior. > . I don't buy the assumption that customizations of auto-mode-alist > are frequent enough to make that an important factor in these > decisions, let alone suggest that users should always do that if > they want to try the *-ts-* modes seriously: Why wouldn't they be frequent? It's the only way for the user to have file format supported, where we don't support it OOTB. The customization of auto-mode-alist might also happen for the user automatically. When the user installs a third-party package, such as json-mode, from ELPA, that modified auto-mode-alist through package autoloads. Having it modified again by 'M-x yaml-ts-mode', but only for the duration of the current session, would be surprising and odd. If I were a new user, I would be questioning both why the mode association changed, and why it didn't persist between sessions. > - IME, auto-mode-alist is relatively rarely customized for modes > that are included in Emacs (e.g., I don't customize entries of > any such modes), for the simple reason that it is very rarely > needed. I'm talking about modes which are not included in Emacs. But having the association for .rb files rewritten when somebody invokes 'M-x ruby-ts-mode' would be weird too. It will make it a pain in the ass for me to test ruby-ts-mode, for one thing. Or js-mode -> js-ts-mode, or python-mode -> python-ts-mode. People should be allowed to experiment without having to figure out how one can undo an automated change like that. > - Customizing auto-mode-alist is not the easiest task, it > requires good knowledge of Emacs regexps and alists. So > asking anyone who wants to try using the tree-sitter modes to > do that is not the best idea from the POV of user-friendliness. They will have to learn how to do that anyway, because the auto-mode-alist alterations from your patch won't persist between sessions. To make it easier, we could put examples in the Commentary of each ts mode. That's something that has been a common practice with third-party mode, so there are a lot of examples of this code out there anyway. > - OTOH, I'm quite sure that people who do already customize > auto-mode-alist for built-in modes are more advanced users and > will be able to overcome any problems that could be caused by > modifying auto-mode-alist as side effect of activating the > mode. Adding elements to auto-mode-alist is easier than removing them. > . Last, but not least: I think someone who turns on a tree-sitter > mode in some buffer is much more likely to want to use that mode > in more than that single buffer than the other way around. And if > for some reason they are disappointed soon enough, just restarting > the Emacs session will get them back the old behavior. Which > again tells me that if we accept your proposal, we will annoy more > users (with the need to modify auto-mode-alist) than under my > proposal. Someone who turns it on for the first time doesn't know yet whether they want to use it or not. It hard to gauge the percentage of those who will. And again, those who will want to, will have to learn how to deal with auto-mode-alist anyway. For some modes that could be avoided with e.g. (require 'yaml-ts-mode), but for others (e.g. python-ts-mode) it could not. Why proliferate special cases?