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: Cutoff date for adding ruby-ts-mode? Date: Fri, 30 Dec 2022 23:42:50 +0200 Message-ID: <78ee732a-21a1-3443-2a0e-85343272e0ba@yandex.ru> References: <00b1ed5e-271b-fab7-cace-b6a04ac6fd46@yandex.ru> <83mt7571cu.fsf@gnu.org> <9fd271e5-5501-83de-0185-27a3c40eed26@yandex.ru> <83mt746d5z.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="25742"; 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: emacs-devel@gnu.org, pedz@easesoftware.com, monnier@IRO.UMontreal.CA To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 30 22:43:46 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 1pBNAI-0006We-5T for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Dec 2022 22:43:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBN9Z-0001zq-0u; Fri, 30 Dec 2022 16:43:01 -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 1pBN9W-0001zO-9I for emacs-devel@gnu.org; Fri, 30 Dec 2022 16:42:58 -0500 Original-Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pBN9T-0000VH-QK; Fri, 30 Dec 2022 16:42:57 -0500 Original-Received: by mail-ej1-x634.google.com with SMTP id tz12so53615002ejc.9; Fri, 30 Dec 2022 13:42:53 -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=POXLej4hZd8fGM8BPu+2CPoxJiW5/Da8KDCigzU3q94=; b=Ihqr3OBEWdxhgyKKu2JVlVNJsbSrXSfhNz9c5SmX5l7e9Adbw284LrIUsf84tr/2IE p93sGikM3DtoTBsUp4a0u0Lh/eqM41bVZzVimmnf+Lg0TNXVdYZ4Qj+sZg54zU5y0Rat NoCS/vDbk3HvN9Yqn+Nefkh2dQnMJ2Y1nuTw+3SVrj7sj2MBiytoDtPWtwbmnCvbE5Gh cfmS8Rh2/sZBoKBgRITMiptJ6ptK9ogJtq67wSh4BZxARAMfn4qr4DS5IKgDy8VQNfTM VxlR+ga16Js8tA18GuoFPv3Rkic+2XpsVXTeOZ7MxcLCkdJ2Z6ctRBDH52djOR1A8jQW QLlQ== 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=POXLej4hZd8fGM8BPu+2CPoxJiW5/Da8KDCigzU3q94=; b=gZs/ilMXGpgK39VGvouX9DCzOo9nha9Duf8y8RSIlNeelCpt+mSoRJLb2AbPSbHYBs olTmniH5VEBwfm5uQae+wazVdFGLLiz7mEtz/YyNY6oDRtje0kViQkY+ypP+FQZ2Vw2d kgkzrXkHrsop3WoxGfQO6cxSk/Lu9joQtAUgnLOKHD4RvC5zhPG5Xa+Pk1pgxZd0rmTF b2Zl8UkNQSuA4a5BRXjNprOO76GqRbgRgX/l7+9j+o9t3FFV7tYFWxVognCDQ/Vsyjge 9F2gr03tVYqeIHjlQwnwFHlIVXvqlnN/fy2VPXI3VPULrRTbaZGofWj31PD9YpUdygfr 35BQ== X-Gm-Message-State: AFqh2kreIZ+K+7Z5wLSgUSV8NXCBS1AdwcqOnawwH8NseQGzFC3RpBHr zQ6faoatQ75fjwUm0Y7ZP7qdQS/GPKs= X-Google-Smtp-Source: AMrXdXvD3mUbn3F8O9xnXSF35nXJ7au1KJIkGAjfN2e0dg9I6WBML4sAQ7XZlXSjHZRAbsndWecJ8g== X-Received: by 2002:a17:906:ae94:b0:7c0:dcc5:756c with SMTP id md20-20020a170906ae9400b007c0dcc5756cmr27201865ejb.71.1672436572267; Fri, 30 Dec 2022 13:42:52 -0800 (PST) Original-Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id x20-20020aa7d6d4000000b0047b252468a4sm9864218edr.78.2022.12.30.13.42.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Dec 2022 13:42:51 -0800 (PST) Content-Language: en-US In-Reply-To: <83mt746d5z.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=raaahh@gmail.com; helo=mail-ej1-x634.google.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-1.146, 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:302137 Archived-At: On 30/12/2022 18:59, Eli Zaretskii wrote: >> Date: Fri, 30 Dec 2022 17:32:47 +0200 >> Cc: emacs-devel@gnu.org, pedz@easesoftware.com, >> Stefan Monnier >> From: Dmitry Gutov >> >> Speaking of the method, how do you feel about renaming a file? >> >> If ruby-ts-mode is going to live in the same file as ruby-mode, perhaps >> the more neutral file name ruby.el would be proper? This would be in >> line with the scheme used by js.el and python.el. > > I'd like to avoid any more decisions related to *-ts-mode's, let alone > binding ones. I'd like to leave that for the future, when we > (hopefully) will have a clearer picture of how best to mix > tree-sitter-supported modes with the traditional ones. > > So renaming now doesn't sound like a good idea to me. I like to defer decisions too, but this comes with consequences. E.g. if we release ELPA packages with certain names, and later change the names, people who already installed the previous names will stop getting updates, but won't know to switch to the new names. Unless they read about it on Reddit or etc. So it's something to do as rarely as possible. >> This is not an idle lets-decide-it-later question because I want to have >> some later releases of these modes in GNU ELPA, and we'll want to have >> the built-in packages properly shadowed when someone installs a new >> version. (Perhaps Stefan has an advice here, so Cc'd). >> >> I see several (require 'ruby-mode)-s in third-party packages. There are >> not too many of them, I could just go around and ask everyone to replace >> that with (or (require 'ruby nil t) (require 'ruby-mode)). Or we could >> have a compatibility stub in Emacs 29 where ruby-mode.el just calls >> "(require 'ruby) (provide 'ruby-mode)". >> >> We don't often rename files also because of 'git log' problems, but we >> have a decent (and simple enough) plan to improve that in bug#55871. >> >> Alternatively, we break from the common scheme and put the modes in >> separate files, one depending on the other. Then they'll have to be >> separate GNU ELPA packages (I think), and we'll need to synchronously >> bump version and required-version in them every time when making >> interrelated changes in the future. > > I'd prefer this alternative for now (modulo the separate ELPA packages > part, which I leave for you to decide: they could also be a single > package from my POV). If nothing else, having separate files is > similar to what at least some other *-ts-mode's do. When we revisit > these issues in the future, we'll be able to make the decisions about > all of them. Okay. I wonder what's going to happen if we release Emacs 29 with ruby-mode and ruby-ts-mode in separate files, and then later add a package called 'ruby' to ELPA with ruby.el containing both modes. Will the autoloads file from an ELPA package always take priority over the built-in autoloads? If yes, then we don't have to do anything now. Hopefully that's not undefined behavior. Alternatively, it would be possible to release two files as one ELPA package, but it would seem to require a third file: one matching the package name, ruby.el.