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: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 04 Dec 2017 19:40:42 +0200 Message-ID: <83d13uxug5.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> <83o9nexy48.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512409270 28279 195.159.176.226 (4 Dec 2017 17:41:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 17:41:10 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 18:41:04 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 1eLujm-0006y2-EU for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 18:41:02 +0100 Original-Received: from localhost ([::1]:44479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLujt-000721-Jm for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 12:41:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLujj-00070F-TF for emacs-devel@gnu.org; Mon, 04 Dec 2017 12:41:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLujf-0004mP-Nw for emacs-devel@gnu.org; Mon, 04 Dec 2017 12:40:59 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLujf-0004m8-K4; Mon, 04 Dec 2017 12:40:55 -0500 Original-Received: from [176.228.60.248] (port=4391 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLuje-0001BU-Db; Mon, 04 Dec 2017 12:40:54 -0500 In-reply-to: (message from Stefan Monnier on Mon, 04 Dec 2017 12:12:48 -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:220714 Archived-At: > From: Stefan Monnier > Cc: dgutov@yandex.ru, emacs-devel@gnu.org > Date: Mon, 04 Dec 2017 12:12:48 -0500 > > > The code which supports PREV-CHUNK is already in Emacs, so the > > question IMO is "why remove it"? > > ?Which code is that? prog-indentation-context and its support in prog-widen. > > If we want to try to get this into > > Emacs 26, we should strive to make the code changes minimal, ideally > > zero. Once all we are left with are documentation changes, the > > feature can land on emacs-26 right now. > > Zero is not the intention: for the doc changes to be valid, we need to > add a few `widen` calls in places like indent-according-to-mode. If those calls are conditioned on MMM actually being active, then existing behavior will remain unchanged, and we are good. > But I'd be fine keeping the old prog-indentation-context if you want. Actually, let me try to understand why any changes to the existing code, apart of _adding_ those few 'widen' calls, are at all necessary. Please bear with me. What I see in the branch is this: 1) the calls to prog-widen are replaced with calls to widen. 2) some calls to widen are added 3) prog-indentation-context is removed 4) prog-first-column the function is removed, and its calls replaced with accessing the (existing) name-sake variable For 4), we already agreed that keeping a function is better. Since prog-widen already calls widen if prog-indentation-context is nil (which it is by default), calling prog-widen without setting up prog-indentation-context will just call widen; this magically takes care of 1). For 3), if we leave prog-indentation-context in the code, and also allow direct calls to widen in modes which don't want to use the context, we are not losing anything, while leaving the option of using the context to those modes which will want that. This currently cannot be used by MMM (AFAIU), but other features which need embedded code, such as ANTLR, could still use it, and even MMM will be able to do that if it is extended. 2) can be taken care of as indicated above, thus avoiding any possible effects on existing behaviors when MMM is not active. If you agree with the above, then we can have the cake and eat it, too. Or am I missing something?