From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Wed, 6 Dec 2017 20:41:21 +0200 Message-ID: <41e3f343-816f-d2db-6575-6ef43d54957f@yandex.ru> 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> <83d13uxug5.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512585701 28540 195.159.176.226 (6 Dec 2017 18:41:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2017 18:41:41 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 06 19:41:37 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 1eMedU-0007Kc-RV for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2017 19:41:37 +0100 Original-Received: from localhost ([::1]:57016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMedc-000152-6I for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2017 13:41:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMedO-0000zZ-Ue for emacs-devel@gnu.org; Wed, 06 Dec 2017 13:41:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMedK-0003ZE-U3 for emacs-devel@gnu.org; Wed, 06 Dec 2017 13:41:30 -0500 Original-Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:34042) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eMedK-0003Xs-Jb; Wed, 06 Dec 2017 13:41:26 -0500 Original-Received: by mail-wm0-x241.google.com with SMTP id y82so24181924wmg.1; Wed, 06 Dec 2017 10:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RjNzcuwG1OcZ7HjLQ+XjSmRdUCXifgfm40a8vVyU8CA=; b=BkjNV7LebF/3VINXSifB+tzp8mM8E1ySv1mgwo4nPQJNKr0bkUYX0vxcqXHmxp6rlu bQAVfq307uBgZ9PsmCd4yue3PB7eKDcnmTHcn0Nc7iL5X/O45Pjx8IWEo8wSfAuMCkXF MYgnPBn+2+5KpQcGvyp3EiUksABLEulrLkfJIMbw3qJdSjC+FtuaE/NQjTy4fMs2QQ2V hvqdteBj1xZL1S38c9rGxuZ4hcpez1IbWbkjyY7WsgvS0gnKDoZjsEIIn59LYfKpca/P AAvGlpgxY6yRwzPTfAvGxeCNHYeodM9BnlAGBYKeH6ApyNjtJAKPFrBemv+Artg+Ckbu I9MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RjNzcuwG1OcZ7HjLQ+XjSmRdUCXifgfm40a8vVyU8CA=; b=tW4g3Ug1QSPPabLnYm5ram+w3qTiIz3L30UcUqcMnIwGwbDgtoKcnTuk0jlLZ5WWRW 7rrHrJbgeuNFHfIwMkx90IhkNiWuqoFYQ24l5m7rmR4qIpu3RzhJ1ICPpmzNqkL3Iyci Ymsejh00ktVLfzciE2GAdPCihbNzU7MSlrImQs7vqR8h6N6/4xn0h+8sVUMQhFZdCkuH YfpQXtnIt2P2OmXsYREhOnYDsu8rhwen4dqkgrsnbq88iSJOHkjikJnC7sKdk9vfXhvF q4Balt/4ztP7+Xz6op/GMYSnUEM/XKCr9ihcX1PunVArBJYPMEgXCY+qfkRK8fEd1BQU eCDA== X-Gm-Message-State: AKGB3mJiqTeiGeSryvsZfc/dRBhRxcEKc9ezF0YNTL3skT+Woypna5RQ FWU+gqThQUnrbyr0P1sQ9Bze2C5u X-Google-Smtp-Source: AGs4zMZWJsFLCZHywvsZXHqBz70+PBo9USjbtRPYBYx/JYG5SsgpOP1tdVWCCaAjoC2tnHwAaOdC/A== X-Received: by 10.28.14.141 with SMTP id 135mr2165945wmo.104.1512585685102; Wed, 06 Dec 2017 10:41:25 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id m133sm3797179wmd.40.2017.12.06.10.41.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 10:41:23 -0800 (PST) In-Reply-To: <83d13uxug5.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::241 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:220768 Archived-At: On 12/4/17 7:40 PM, Eli Zaretskii wrote: >> 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. To reiterate: Yes, this code has been in Emacs source tree for two years. But: It's only used is one line in antlr-mode.el, which wasn't supposed to start using it before Emacs 26 was released anyway. But it's easy to change. On the flip side, prog-indentation-context is *only* well-supported in python-mode. Not in css-mode, js-mode, ruby-mode or others. In those, you still have to combine its binding with narrow-to-region, essentially obviating the need for the second element in the list. In short: we have the code, and even Emacs, after the said 2 years, isn't supporting it properly. PREVIOUS-CHUNKS isn't supported anywhere either. And, in that case, there's no code corresponding to it. Just a few pieces of documentation. >>> 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. No, the widen calls are conditioned on whether we want all indent-line-function calls to start in fully widened state. Which seems like an obvious improvement. Point is, they won't be allowed to call 'widen' themselves, so the addition of 'widen' to indent-for-tab-command and indent-according-to-mode makes them act on the whole buffer in the simple case. > What I see in the branch is this: > > 1) the calls to prog-widen are replaced with calls to widen. No, they are not. The calls to prog-widen (or widen) made in indentation related code are removed. The only place in the diff where prog-widen was replaced with widen, is where it probably shouldn't have been in the first place (that code is not inside indent-line-function; only tangentially related). > 2) some calls to widen are added In code that later either calls indent-line-function or beginning-of-defun-function. > 3) prog-indentation-context is removed Yup. > 4) prog-first-column the function is removed, and its calls replaced > with accessing the (existing) name-sake variable Yes. It's not a hard requirement, but there doesn't seem much benefit in keeping it a function. And if it's a function, what will it return? > For 4), we already agreed that keeping a function is better. I did not. Allow me to post a quote from my other message: If we keep it a function, do we also have a variable prog-first-column? Then, some consumers might have doubt which ones to use, and might opt to reference the variable. In that case, we lose all benefits of having it a function (like making its implementation somehow smarter later), and the only benefit remaining is backward compatibility of having a function with that name. But! Like with PREV-CHUNKS, prog-first-column (and the later prog-widen) are supposed to be used by the major modes only. There are no references to either of these functions in the latest antlr-mode.el, and there shouldn't be. And as long as all the calls to that function are inside Emacs, we're free to change it however, including turning it into a variable. > 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. As I hopefully described, the above does not make sense, unfortunately. > 2) can be taken care of as indicated above, thus avoiding any possible > effects on existing behaviors when MMM is not active. Not sure I understand you here.