From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 04 Dec 2017 11:35:53 -0500 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512405416 730 195.159.176.226 (4 Dec 2017 16:36:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 16:36:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: acm@muc.de, tom@tromey.com, emacs-devel@gnu.org, spinuvit@gmail.com, Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 17:36:51 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 1eLtjb-0008D1-PQ for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 17:36:48 +0100 Original-Received: from localhost ([::1]:44033 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtjj-000423-2O for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 11:36:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtiz-000412-HB for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:36:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLtiy-0004Tm-Hj for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:36:09 -0500 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:63032) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLtiu-0004SO-Is; Mon, 04 Dec 2017 11:36:04 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GmEgAAeSVa/7mYWxdcGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYM8gVSOLY8TgX2ZFoVFAoU0QxQBAQEBAQEBAQEDaCiFJAEEAWwNBQsLDSc?= =?us-ascii?q?SFBgxii0IqgghAoo2AQEBAQYCASWFUYM/gyuEeoYfBZMaj1KhCyiHNJgHNiOBT?= =?us-ascii?q?TIaCDCCZIJRHBmBbCOICoJHAQEB?= X-IPAS-Result: =?us-ascii?q?A2GmEgAAeSVa/7mYWxdcGwEBAQEDAQEBCQEBAYM8gVSOLY8?= =?us-ascii?q?TgX2ZFoVFAoU0QxQBAQEBAQEBAQEDaCiFJAEEAWwNBQsLDScSFBgxii0IqgghA?= =?us-ascii?q?oo2AQEBAQYCASWFUYM/gyuEeoYfBZMaj1KhCyiHNJgHNiOBTTIaCDCCZIJRHBm?= =?us-ascii?q?BbCOICoJHAQEB?= X-IronPort-AV: E=Sophos;i="5.45,359,1508817600"; d="scan'208";a="10721725" Original-Received: from unknown (HELO pastel.home) ([23.91.152.185]) by smtp.teksavvy.com with ESMTP; 04 Dec 2017 11:35:53 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 2130E61367; Mon, 4 Dec 2017 11:35:53 -0500 (EST) In-Reply-To: <83tvx6xzgl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Dec 2017 17:52:26 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.36 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:220705 Archived-At: >> Eli, we already have a feature in Emacs (prog-indentation-context) that >> does not adhere to your (unreasonably high) requirements. > 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. > I don't think this requirement is unreasonably high, as those > languages are still pretty much the mainstay of the industry, and > definitely used by many Emacs users. Apparently, this has not been enough motivation for the last decade, so I'm not holding my breath. Including the new proposal into Emacs may provide an added incentive if MMM-support becomes sufficiently common that CC-mode becomes really the odd-one out (tho it's just an incentive and CC-mode is the odd-one out in many respects already). > 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. >> 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). >> 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. > I wonder why did you discard that. > It's existing functionality, pretty lightweight, which was in Emacs > for some time, and is reasonably well documented. And it already > satisfied your requirement of not allowing sub-modes to widen. Why > not leave it alone? What am I missing? >>>> Transitioning from prog-indentation-context to the new approach is very >>>> easy. >>> That's what I thought. And that's why we should do that >>> simultaneously with landing the new approach. There's no reason to do >>> that earlier. You mean we should provide patches for those codes using prog-indentation-context? Doesn't Dmitry's branch already do that? > I don't see the incompatibilities. Basically, you replaced prog-widen > with widen, Actually, no. The replacement for prog-widen is more like #'ignore (remember: prog-widen is for major modes who want to "narrow to the current chunk's boundaries", but with the new arrangement, the major mode's code is already called with such a narrowing in place). > IOW, the transition could be much smoother than it will be if we > actually remove that stuff, because I don't think there's any > incompatibility here which would disallow direct calls to 'widen' > and/or leaving prog-indentation-context at its default nil value. Or > maybe I'm missing something again. But if I'm right, and if we can > make the necessary changes limited only to the documentation, then it > could well make it into Emacs 26. So I think it is worth our while > to make some effort in that direction, if at all possible. Then let's focus on the doc plus adding a few calls to widen in places like indent-according-to-mode. Stefan