From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Cutoff date for adding ruby-ts-mode? Date: Fri, 30 Dec 2022 10:16:33 +0200 Message-ID: <83mt7571cu.fsf@gnu.org> References: <00b1ed5e-271b-fab7-cace-b6a04ac6fd46@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16538"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, pedz@easesoftware.com To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 30 09:17:32 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 1pBAa3-00047I-A6 for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Dec 2022 09:17:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pBAZI-0006Gb-5T; Fri, 30 Dec 2022 03:16:44 -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 1pBAZC-0006Ce-Is for emacs-devel@gnu.org; Fri, 30 Dec 2022 03:16:38 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBAZB-0006xv-HN; Fri, 30 Dec 2022 03:16:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=11vISiISCYSnBrGT2+Zzl1urP0mVBRXdsn303UJHik8=; b=Vmh2vyuKELS4 P+vNUuaEdE/4+6dzhl50lDW9swaDsoOTkyuuPO6lIIruzzuUmfn2xOSwrIuSPTp9Om8fg2xObSuxQ RBgMl3xgXuruiUtvz7cebyynbApWSgFdMIhD9LSPNM9TDTQaX2pqxDQ+YKFaIbRuLqtx/p+cKAwdj yd2WBvoX/0z6tuf4F52/AqoOLROw231kYGwVp0a34GzwY9JI8ngWzV3t70Gefi+uGDfpd1aH6Cyjq UaWlIXA86mGlq8OxLbeUgq5kJccIuCUfqWeNF/UH63F+juwCGYMKI3+KvG8h4jBqYtQBOteXtIZO6 r+FN9Z9vZQIlqVTmMZtmLA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pBAZ8-00064I-MF; Fri, 30 Dec 2022 03:16:37 -0500 In-Reply-To: <00b1ed5e-271b-fab7-cace-b6a04ac6fd46@yandex.ru> (message from Dmitry Gutov on Thu, 29 Dec 2022 23:39:37 +0200) 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:302082 Archived-At: > Date: Thu, 29 Dec 2022 23:39:37 +0200 > Cc: Perry Smith > From: Dmitry Gutov > > Hi all and Eli in particular, > > How close are we to "hard freeze" date of Emacs 29, after which no new > tree-sitter modes should be added? You have a day or two, and I hope this should be enough for adding new features. (If they have still some rough edges, that could be fixed later on.) > I'm told the copyright papers might be signed next week. > > The code is largely functional: font-lock just needs minor updates; the > indentation has more problems, but it's still probably better to have > the new mode in Emacs 29, rather than not. So I suggest you install that ASAP. > Also regarding indentation, Ruby community uses a bunch of different > styles, and it was my impression (could be wrong, though) that Perry > wanted to at least have ruby-ts-mode be able to use a different style > than what is currently ruby-mode's default. To that end, he implemented > a couple of user options. > > In bug#60186, I also implement a bunch of options that allow similar > flexibility to the users of "plain" ruby-mode. I believe rather than > have different incompatible options, it would be better to unify them > between the modes, at least where the capabilities match, to use the > same options. I agree that having compatible options makes sense, provided that changes in ruby-mode that affect existing/default indentation style and font-lock are relatively safe. > So... if there is still time to get ruby-ts-mode in (and give it a > little polish), it might be a good idea to get the patch for bug#60186 > in first. Alternatively, it could come with non-customizable indentation > (options would be added later), or it could have a set of customization > points which we'll promptly deprecate right after (ones that will become > redundant). > > Or we defer all that and release both new options in ruby-mode and > ruby-ts-mode from master to GNU ELPA. It's up to you. If the above-mentioned method suits you, we can have that on the release branch.