From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Removing prog-indentation-context Date: Fri, 25 Mar 2016 02:53:31 +0200 Message-ID: References: <20160322022539.16038.77264@vcs.savannah.gnu.org> <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> <56F293E7.2000703@online.de> <87a8lpnusg.fsf@gmail.com> <83r3f12oo5.fsf@gnu.org> <56F2D156.9040401@online.de> <83k2kt2i51.fsf@gnu.org> <56F2E643.4060903@online.de> <592bbafa-76ae-49d9-b5cd-644b3619a0d8@default> <87poukn8pl.fsf@gmail.com> <837fgs35q3.fsf@gnu.org> <8337rf3m4u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1458867229 8186 80.91.229.3 (25 Mar 2016 00:53:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 00:53:49 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 01:53:45 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ajG0W-0007BX-Nx for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 01:53:44 +0100 Original-Received: from localhost ([::1]:53514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajG0V-0006iA-Nd for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 20:53:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajG0S-0006i4-Fw for emacs-devel@gnu.org; Thu, 24 Mar 2016 20:53:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajG0N-0000N6-F5 for emacs-devel@gnu.org; Thu, 24 Mar 2016 20:53:40 -0400 Original-Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]:36524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajG0N-0000N1-3q for emacs-devel@gnu.org; Thu, 24 Mar 2016 20:53:35 -0400 Original-Received: by mail-wm0-x22c.google.com with SMTP id u125so5635253wmg.1 for ; Thu, 24 Mar 2016 17:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Z88ExkwCNfLUPlkD7+gu90d4sF0PCi2UsPzSpMxKexU=; b=BMTXjTdj/HUl6ph0wkW+CrhO6nZymGWluu05nmb8dt6STe4s28ZdhJjJ1UcXztIacL ZDIP8Reg6+K0zMxsPP/LFrwB69gRKaOmSROfhSiiAKgZt9kKujPl7K8+noaL2VG5kHEp DGtLO9r83putSngOdZHb1Pm+cEPAFwbwGwvjZgd09+jOlot1TwJotK2Me9OFH0cAatn1 s2UZaoPpUFakBTeD62e4Krl1ATqgzWmF8lRrI/boqZI+l5UGLHBlYfnBNwe6hNysUXnz DJHms7p8UUSyifEies2oUHKMbKTE/L9tEe3ohwxhddZGvaX6xXW89GfcXUTu30iPuWbC IQEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Z88ExkwCNfLUPlkD7+gu90d4sF0PCi2UsPzSpMxKexU=; b=K8N0jFkZ3IqUFh9CVyd8E0fjzH2OZoSiy3GuOTjEBVaxij/toObMSmCvpeVxlo4YWM 1qXD6SpPAWkk3W7OcCLY6ztwF6xB39eYffcnSplXyyq8nROfMmRTTpQYtA1GhiXQv+gX t3N/kRiW3Y3aHWvOoRQ1Bquy0giERuu24zqn99uWooEZtX/tOuleleY8Z1pXRsIi9EmM iPRDdHTT6f3aZQPe3A4IWiHmYD2LwRVGBwpR+P58qMUI6D4JUuFvxw61VS9hOYsT/71o mIN2NbmV8/lkerN47nWb8qmGSu5vso82VGqMf3zPPARMP7OohpaP1/aOxhnNFNpqFcNB 8kyw== X-Gm-Message-State: AD7BkJKmOqtBAN3lE7CVEr5xmDenf+amsTq7+LX/nNZhin6RW510ZCtIGqTfcVpH5x0WVw== X-Received: by 10.194.216.2 with SMTP id om2mr12382856wjc.164.1458867214001; Thu, 24 Mar 2016 17:53:34 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id hq2sm9703506wjb.3.2016.03.24.17.53.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2016 17:53:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202207 Archived-At: On 03/24/2016 08:55 PM, Stefan Monnier wrote: > FWIW, I think it's a mistake to remove it. We need to move forward on > multi-mode support, and even if prog-indentation-context is not "the > right way" (I doubt there is such a thing anyway), Are you against removing it in Emacs 25.1 in particular (but retaining it, for now, on master)? We don't include support for it even in the built-in major modes, save one. And python-mode doesn't support the more controversial third element. The built-in antlr-mode doesn't use it either, even though it was supposed to be the main beneficiary. It's silly to expect third-party authors to adopt it when we haven't done so ourselves. By that measure, prog-indentation-context has failed, at least for inclusion in the upcoming release. > adapting some major > modes to it will most likely not be wasted time, because it will most > likely make it easier to adapt those modes to whichever other approach > we may switch to in some future. Respectfully, I more disagree than agree. If we put aside the PREVIOUS-CHUNKS element, we have two elements left: - (START . END). Yes, making modes use `prog-widen' instead of `widen' is a good change, but it's a trivial search-replace. There's not much benefit in doing it in advance, or waiting for third-party code to catch up, etc. The proposed alternative: hard widen limits. If it's adopted, it'll make using prog-widen simply unnecessary. - FIRST-COLUMN. The proposed alternative: prog-indentation-function that returns a column number. If we choose this one, it's likely to result in a rather natural code transformation in modes adopting it. It's also a different one that what we'd make to use FIRST-COLUMN, at least if we take smie and js as examples. > More importantly, I don't think we'll ever agree on what should be done > in this respect because we'll only know what works and what doesn't > *after* we install it and make it "the official way". Why? The advancement prog-indentation-context offers is rather minimal for new multi-mode packages to crop up overnight. And even if they would, they could just as well test their changes using the master branch (we do have a certain fraction of users continually building from it, even if they don't participate in the development). On the other hand, you have maintainers of the two active multi-mode packages (polymode more than mmm-mode) right here, in this discussion. And we're both capable of building Emacs from master, as well as implementing features that depend on it. That must be true for Christopher as well. > The "run with it" part will hopefully help align the > various major modes, thus making it easier for a second candidate to > make further progress, and so on and so forth. Yes, well, it didn't, so far. And there are better ways to evaluate an API proposal, such as asking for patches that add support for all of its parts, in advance. If the demand for multi-mode support is less than we'd hope (resulting in fewer or slower patches), it can well incubate on a feature branch. In the meantime, the basic needs of the web development crowd are being served by web-mode (which is not an actual multi-mode, and would likely not benefit from features discussed here). So it's not like a lot of people's is at a standstill because of our indecision. > At least, that was the reason why I decided to go with > prog-indentation-context. It was not because I thought it was The Right > Way, the final word on the matter. Emacs's development cycles are long, and backward compatibility promise is significant. I don't want to get into situation with multiple blessed solutions, all inferior in some way, all with spotty support in existing code.