From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 04 Dec 2017 18:56:02 +0200 Message-ID: <83fu8qxwil.fsf@gnu.org> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <20171130214621.GA22157@ACM> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <83lgil1qme.fsf@gnu.org> <83d13x1j2s.fsf@gnu.org> <34abea95-c7f7-e8fa-8407-8c2fd2a4cfe1@yandex.ru> <83y3mkzw1n.fsf@gnu.org> <83mv2zzv7z.fsf@gnu.org> <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> <83k1y3zq2n.fsf@gnu.org> <83tvx6xzgl.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512406609 31741 195.159.176.226 (4 Dec 2017 16:56:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 16:56:49 +0000 (UTC) Cc: acm@muc.de, tom@tromey.com, emacs-devel@gnu.org, spinuvit@gmail.com, dgutov@yandex.ru To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 17:56:45 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLu2u-0007yY-MR for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 17:56:44 +0100 Original-Received: from localhost ([::1]:44111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLu32-00074N-1R for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 11:56:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLu2W-00074I-Au for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:56:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLu2S-0005TD-Ge for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:56:20 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLu2S-0005T8-Bv; Mon, 04 Dec 2017 11:56:16 -0500 Original-Received: from [176.228.60.248] (port=4374 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLu2R-0000Mc-FO; Mon, 04 Dec 2017 11:56:15 -0500 In-reply-to: (message from Stefan Monnier on Mon, 04 Dec 2017 11:35:53 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:220710 Archived-At: > From: Stefan Monnier > Cc: Dmitry Gutov , acm@muc.de, tom@tromey.com, spinuvit@gmail.com, emacs-devel@gnu.org > Date: Mon, 04 Dec 2017 11:35:53 -0500 > > > Emacs development is not only about not losing existing features. It > > is mainly about gaining new important features. Here you are adding a > > feature that I think is important enough for us to try make it support > > C-like languages. > > His proposal is reworking prog-indentation-context. > CC-mode doesn't support prog-indentation-context, so it's no surprise > that it doesn't support this replacement= and I don't see why suddenly > we should first get CC-mode to support it before the replacement can > be installed. Not "first", "together with", or at least "soon enough after". > Apparently, this has not been enough motivation for the last decade, so > I'm not holding my breath. Well, Alan just said he will try to make that happen, so I _am_ holding my breath. > > Maybe I'm missing something, but what's the equivalent of PREV-CHUNK? > > There isn't any. PREV-CHUNK is probably a good idea somewhere in some > cases, but we haven't found those cases yet. But it's already in Emacs. So the question IMO is "is it such a bad idea that we need to get rid of it right away?" > >> We keep 'prog-first-column' from that proposal > > But it was a function, and you made it a variable. This will get in > > the way of compatibility, and also potentially will make future > > extensions harder. Why not keep it a function? > > Agreed, it should be a function (which can internally just lookup > a variable, in its current implementation, but API exposed to major > modes should be the function). That's what it is: a function that looks up a variable internally. > >> and instead of allowing MMM to indicate the chunk bounds through > >> prog-indentation-context, we allow MMM to apply narrowing directly, and > >> that modes honor it. > > This simplification also took away some of the features, like the > > ability to nest restrictions. > > I do not know what you're referring to. AFAIU, prog-indentation-context could support a way to nest restrictions, because prev-chunk could be a function. > You mean we should provide patches for those codes using > prog-indentation-context? Doesn't Dmitry's branch already do that? Not for ANTLR whose latest versions are maintained outside Emacs, AFAIU. > > I don't see the incompatibilities. Basically, you replaced prog-widen > > with widen, > > Actually, no. Again, I might be missing something, but "git diff" says I'm right. > Then let's focus on the doc plus adding a few calls to widen in places > like indent-according-to-mode. I'd still like to understand why those additional calls to 'widen' are needed. Doing that seems to contradict what we want to ask major modes not to do in their indentation code.