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: Mon, 11 Dec 2017 00:43:58 +0200 Message-ID: <143d80b7-4612-7b21-b371-f8d8d0c607df@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> <41e3f343-816f-d2db-6575-6ef43d54957f@yandex.ru> <838tecuqjb.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 1512945883 29701 195.159.176.226 (10 Dec 2017 22:44:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 22:44:43 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 10 23:44:39 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 1eOAKt-0007WW-6N for ged-emacs-devel@m.gmane.org; Sun, 10 Dec 2017 23:44:39 +0100 Original-Received: from localhost ([::1]:50038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOAL0-00087t-5Z for ged-emacs-devel@m.gmane.org; Sun, 10 Dec 2017 17:44:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOAKO-00087Z-7b for emacs-devel@gnu.org; Sun, 10 Dec 2017 17:44:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eOAKJ-0007lW-8k for emacs-devel@gnu.org; Sun, 10 Dec 2017 17:44:08 -0500 Original-Received: from mail-wr0-x242.google.com ([2a00:1450:400c:c0c::242]:37159) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eOAKI-0007l1-TT; Sun, 10 Dec 2017 17:44:03 -0500 Original-Received: by mail-wr0-x242.google.com with SMTP id k61so15730585wrc.4; Sun, 10 Dec 2017 14:44:02 -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=x2rHOB9iXvpdhSONFv5+ds0CIAvcSXQSREn4+JPIWwM=; b=PUow77gdnVPz2+tFc7+GR+iG1g9/d3Crqs+FuY2lpqKEAXST9zT2k/03coLqSAmuoq CvM9iBUXr49I0NoWzV8HWwg3VTOje7tzhqcOX8FjgXbcM0/kSSvhYn2Xczc4YNeNyMrg AzcVLjys8Cgp+D6Fo74a9zXamtkIbcv+pdOjKOdjRkHs7ow5K5bIEI05xoaWFEPJH0HI ekeJdrONVkHgcvNitRySZFVqoNRHSWbsiLH/J4u6wDBB37cH7qVu9B74XS1HXaOKN1jv UPLLowxEvAt+REHsJCi2/Wg4UbVRh/IWdPWodEs/kXZLhV3yWxmDf1bvS9tjwoCL9eTV YV2A== 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=x2rHOB9iXvpdhSONFv5+ds0CIAvcSXQSREn4+JPIWwM=; b=L2ZMPpKNGbuEhLX65+5KLjAhLUKwGN1X1ASjWGZOCQ5GwGqGVxUsMt9dB6+WxWfa0c WTVuqgx697n4NMGWNd/OgafY3RhEkDVyzKT4cIZiAH1ejAMjkR71l1lE/kyplXAYRwYk X37OnY5DePUtM1zSzK2mOp3itIVEo/dueq984exEUlFHUxQSeOt4SBN8tgAYwNCkfYms zSRKC7m+bkDvEjgktURSWQerSbyqtH93QwfgPT0AOCsJC1M46CZt73LiVP2SjInBstl9 JxaOPh+3cABQBeH/W7IBtn0E3EernPYVamt6nZ18BNt2W69YxcCA/IaHpTHZ3Z7Lgizp MOyQ== X-Gm-Message-State: AJaThX7aXZOp0+O+IjPAnQmETBu3J7r51a71t4wNMZ5yPCelTJiVkei8 NxomX6/duGQMfgj44V75CC2NpIEH X-Google-Smtp-Source: AGs4zMasxTplH75kPUZ3cnIo8Mh5FZKSY4cIhwGi+4lFmrheFaWOs8SV/Fi9TZhtL/LbQIQ/lx1ZAg== X-Received: by 10.223.178.130 with SMTP id g2mr31091535wrd.129.1512945841487; Sun, 10 Dec 2017 14:44:01 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id m133sm7631107wmd.40.2017.12.10.14.43.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 14:44:00 -0800 (PST) In-Reply-To: <838tecuqjb.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:c0c::242 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:220867 Archived-At: On 12/9/17 12:47 PM, Eli Zaretskii wrote: > I think we are failing to communicate. "Not supported anywhere" is > not a reason good enough in my book to remove something. Allow me to clarify: "Not supported anywhere" is, in my mind, a reason to disregard the "2 years" qualifier. It's important to keep around code that's likely to be already used by someone, and it's barely the case here. And the reasons to remove are different ones, and more technical, most of which have been mentioned in this thread already. And we discussed PREVIOUS-CHUNKS before, e.g. in the older thread I just linked to in a reply to John's email. In addition to that, "not supported anywhere" can be a reason to remove PREVIOUS-CHUNKS in particular, because in the original discussion where they've been added, it was understood that the author will follow up with corresponding support for them (to prove the design), which he never did. > We have > there a feature that is a super-set of what you need for the MMM > related support, Not really, no. > Arguing that there's a good reason for removing > prog-indentation-context would need to show how keeping it _precludes_ > some of what you are trying to do, or at least makes it unreasonably > hard. Yes, it precludes us from removing prog-widen and widen calls from indentation code. > And please keep in mind that 2 years without any additional users is > not long enough to prove that this feature is useless. Let's also > keep in mind that this feature was reviewed at the time and admitted > into Emacs, which means Stefan did think at least back then that it > could be useful in practice. It was predicated on some support coming later. Which, again, never did. > We should give people a chance before > deciding it is completely useless and worthy of removal. What kind of chance? The support for it needed to be added *inside* Emacs. It's not "completely" useless. prog-first-column was a good idea, but we have a better idea about the other parts. > Whether we should unconditionally call 'widen' there is now a subject > of a separate discussion. And why is that "separate discussion" not considered finished and concluded yet? I think the result is a fairly solid "yes, we can". > For the purposes of this discussion, the > only issue that should matter is whether using 'prog-widen' instead of > 'widen' in those places will get in the way of the MMM support. Unfortunately, that's not how the issue stands. Not calling widen in indentation functions matters. >> No, they are not. The calls to prog-widen (or widen) made in indentation >> related code are removed. > > I don't think this distinction is important. I presumed that you are > removing those widen calls because you added similar calls on higher > levels, and didn't mention those removals. If that's not so, please > point to specific parts of the patch where the widen calls are removed > without that assumption. Sorry, didn't mention where? Indeed, widen calls are moved to a higher level above the indent-line-function funcall. That's a design which prog-indentation-context cannot support because prog-indentation-context is supposed to be bound inside MMM-specific indentation function. > And I'm proposing to leave that prog-widen call intact, because by > default it's the same as calling 'widen' in the first place. Which means you're actively arguing against the core change proposed in the scratch/widen-less branch. >>> 2) some calls to widen are added >> >> In code that later either calls indent-line-function or >> beginning-of-defun-function. > > This is about widening unconditionally, so it's now unrelated to the > current discussion. If those 'widen' calls are not added, interactive narrowing by the user will affect indentation results in the usual case. Which is probably not what we want to do. >>> 3) prog-indentation-context is removed >> >> Yup. > > And I see no reason for removing it, because if not set to any non-nil > value, it is harmless. If you can explain why leaving it contradicts > support for MMM, please do. Using prog-widen contradicts it. And if we can't promise that it will be used in all indentation functions (or at least those that purport to support MMM), prog-indentation-context, as documented, will be confusing and fairly useless. >>> 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? > > I don't think it matters what it will return. If matters for me, because I want to know exactly what to write to make you happy on this issue. prog-first-column can be a function, but the choice of its backing needs to be made, and as I could see, my train of thought on that issue has not arrived at an any particular conclusion. > What matters is that > (a) keeping a function doesn't interfere with the MMM support in any > way I could see; (b) keeping a function makes the changes fully > backward-compatible; and (c) keeping a function will allow future > extensions where the value returned is not trivially taken from a > variable. I concede points a and c. >> If we keep it a function, do we also have a variable prog-first-column? > > > But if there are good reason to keep the function, while > renaming the variable, I will probably agree to renaming the variable > much easier than I'd agree to removing the function. It won't be just a rename, though, right? The prog-first-column will store only the first element of what was prog-indentation-context. >> 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. > > These all are very weak reasons in my eyes. Keeping the documented > interfaces stable and backward-compatible is a much stronger argument, > and IMO in this case it easily overcomes the above considerations. Even the last one? I though it was pretty solid. But no matter, see above.