From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: Removing prog-indentation-context Date: Fri, 25 Mar 2016 16:45:12 +0100 Message-ID: <877fgqef3r.fsf@gmail.com> 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 X-Trace: ger.gmane.org 1458920754 11224 80.91.229.3 (25 Mar 2016 15:45:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 15:45:54 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 16:45:54 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 1ajTvn-0005oG-F2 for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 16:45:47 +0100 Original-Received: from localhost ([::1]:56724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajTvm-0001Mg-IK for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 11:45:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajTvM-0001MM-35 for emacs-devel@gnu.org; Fri, 25 Mar 2016 11:45:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajTvH-0004kI-3a for emacs-devel@gnu.org; Fri, 25 Mar 2016 11:45:20 -0400 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:34687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajTvG-0004kB-PQ for emacs-devel@gnu.org; Fri, 25 Mar 2016 11:45:15 -0400 Original-Received: by mail-wm0-x231.google.com with SMTP id p65so29449410wmp.1 for ; Fri, 25 Mar 2016 08:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=U8nyJcv6hwTEBetSaKtdXAbtUoqEVUrzcH1T0BxTpAE=; b=xUyF/V3wC4i6X7jwySEnWmAW6ztIUcubcBkwo6EVTPDtuw6YeQalz4t70YOB54r5aw BeobiOOOGM7QYnWMFd3IQakN6AMcjmUv5DB8cHcjQxiNK1KARw7heJbraEPV4cXdQLNf KbDHV+JYKIQdThUDbir/hTzLsdZBEmevRNhI8ZmaFD3slOC3XDxBPeY4rH2OPjPJPYpz Z7bTz8ZAac9yQyABPB6bxWLstEQNeM/DXxDkEOWlttLahDnZOV7XvBHLGZrcP7spvY5L bZGTRhfK2lgXLWmX4jOuHY5cXaBPbiNUJELDH/VaC5X4OHvL4FvhbSHW1tIkDi4z3PE2 HBhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=U8nyJcv6hwTEBetSaKtdXAbtUoqEVUrzcH1T0BxTpAE=; b=AdQ+TsEpeV37yzlmM6Zg4xg7xjww1LV43mu63Cx9Iou1LFaRXujtWkFX2hrSQfp8+i ynIXt3OMpOIHOXh8hJ6kd63l0nCrSMw+ec8emb8eF0st2fFGfuzWLa5xI8123ZvUesgX MoJRd69ka6UyHbs136R9qMk9cfJT1aAi1px5O0ulHTjqbA82nO9jD1QJFoiOHbEzeHkZ 0dLc+xQ0HjSf+P3RmKzhOnxfhr185PckVLnWaDgkKWMKOtFsfNSHDGjEzFJj3mLZ+Bhb aQodd++UUlsDCFYplNWkr43ty2/ej8i2O9ohvZmRIq12mKPF8+cEkVImb+VmKJo3fEwc mIMQ== X-Gm-Message-State: AD7BkJLLfdqDqYgQJUgmeq6SB/ZFm9iIYcYRkX86CcZNbT9ZUHL8WGWlC5JdMWL+h/lyyA== X-Received: by 10.194.23.37 with SMTP id j5mr15330842wjf.171.1458920713954; Fri, 25 Mar 2016 08:45:13 -0700 (PDT) Original-Received: from localhost ([143.176.214.220]) by smtp.gmail.com with ESMTPSA id u4sm12444645wjz.4.2016.03.25.08.45.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Mar 2016 08:45:13 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Fri, 25 Mar 2016 02:53:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::231 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:202225 Archived-At: I think the third element of prog-indentation-context is unlikely to be used by major-modes anyways. Firstly due to inherent complexity of the concept, secondly due to undefined, multi-mode specific, semantics of what to do with those spans/chunks. In any case, multi-mode engines can ignore prog-indentation-context. My bet is that they will always do so, at least because there is no reliable way to identify modes which use it and modes which don't. Vitalie >> On Fri, Mar 25 2016 02:53, Dmitry Gutov wrote: > 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.