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: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 3 Dec 2017 16:35:23 +0000 Message-ID: <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <20171129233238.504B5204F1@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> 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 1512318971 26355 195.159.176.226 (3 Dec 2017 16:36:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 16:36:11 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 Cc: acm@muc.de, tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 17:36: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 1eLXFM-0006S8-Da for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 17:36:04 +0100 Original-Received: from localhost ([::1]:39458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLXFS-0001T1-3Z for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 11:36:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLXEp-0001Sv-6D for emacs-devel@gnu.org; Sun, 03 Dec 2017 11:35:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLXEm-0004m6-05 for emacs-devel@gnu.org; Sun, 03 Dec 2017 11:35:31 -0500 Original-Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]:37523) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLXEl-0004lC-Ik; Sun, 03 Dec 2017 11:35:27 -0500 Original-Received: by mail-lf0-x244.google.com with SMTP id a12so16563164lfe.4; Sun, 03 Dec 2017 08:35:27 -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=6PyqJwVix0LhwouIEho7ys10OLaxekSCJ7KhCbQfFAI=; b=r0zotSMDLlGtayXqhZe23fwj2pVr2AMIqenQTOaBJ71FK5Zj3S9eL5UwVa7lwWiewf PlWCEcoKX3KFcxwvaHlYaZCQy50jfMCBWqi8IHuv2w+FQvczOwbbwikF85CuGn2em5m/ /GJNQRssDp/bRghAt3anfh1WHDZHrECUyNnaIX/UgY4NGfbYNEs4CP6qMj6xkJnQHnIF S4z2eOwN86og+vmaygvaRAjuR9+2DS4Wkl+5UP3Bmo0ErlLGyM8RmQsmjPD8pjWdbZCo aNjDPcnItuMfHFUqqTHC4uO1l2gdmM6rEMrfQHimyGGKsTPLC752dPn6SLSt5odeBzjN iXxA== 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=6PyqJwVix0LhwouIEho7ys10OLaxekSCJ7KhCbQfFAI=; b=iTA6DJu6Mo4MCKm0jMKk7KZApaOk/dFyjTXCwX9+dxIYJhh1R/8e/YFqVEU4bcZUKo kB9qdFj4WBNuljDWK8ksCNJj510Po24cQD2fZZ2WBSylF2k6IlJBq+P+FtOGuMbpdW7m ikokiVL7p7Cd2jwK6k3E7KoLF5mvViJ42zovU0j4UGAoktnEk6xTXMRMw+BfEuIYCdpK Qy2V+uSAZR8u8MsVgoaxt/YhiBYHHARNFfCjakKEBo8XVzmLsI8Uel30QTVA7+Sg0uDG UmCpFLpJSQlx1ycO7dllIXDqtryRMs3qn0VPx2uymsCOhab02a69FhvToGivCo1woeIC A1Cg== X-Gm-Message-State: AJaThX4tk19KGdirlywzChrNc8uNF5VTjVCgipZl2ioykehtYmTU4p0t SMUQc9PJmQIIAgmJ/GpzZXHK641/XQI= X-Google-Smtp-Source: AGs4zMax3XfF/httWFK6NaFj3ICCzVnPiZFEJnFkBUFIsw2MQ8INFI/39YfzKzNnylFllUrKC+aorQ== X-Received: by 10.46.75.9 with SMTP id y9mr7484614lja.57.1512318925843; Sun, 03 Dec 2017 08:35:25 -0800 (PST) Original-Received: from [10.1.2.111] ([194.181.106.111]) by smtp.googlemail.com with ESMTPSA id l85sm2352289lje.72.2017.12.03.08.35.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Dec 2017 08:35:24 -0800 (PST) In-Reply-To: <83mv2zzv7z.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:4010:c07::244 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:220654 Archived-At: On 12/3/17 3:28 PM, Eli Zaretskii wrote: > Because every development environment should first support its own > development well. If it doesn't do that, it's incomplete. OK, I see. But! This feature is *not* targeted at Emacs development. Please don't make me fly out to Scotland and chase Alan down with a broomstick to make this development come through. > Indeed; and C-like languages are quite popular among them. Not in comparison to JS, CSS and HTML. > How will we look if we support JS and Ruby embedded in HTML, but not C > code embedded in Yacc grammars nor Awk snippets embedded in shell > scripts? Both are quite frequent out there. We will be laughed at. We'll be fine. And the actual support is still going to reside in third-party packages for now. This change just makes them possible (or their codebases saner, at least). Except for antlr-mode. It will be able to use it right away (the version inside Emacs, at least). > Convince Alan to do what? To adhere to the current proposal (avoid widening in indent-line-function and font-lock-keywords, to start with). > Do we even understand well enough what are > the problems in CC Mode that get in the way? Who do you think is most qualified to study that issue? We'd probably have to convince Alan to do that as well, unfortunately. I have a rough understanding of the issue, but since I haven't reached a working state, I don't know how many pitfalls there are left. > About the only thing > spelled out in this discussion was the need not to widen. Personally, > I think this is not a grave issue, just some technical problem that is > certainly solvable (you proposed one such solution). Indeed. > But is that all? I imagine the process itself might be trickier than expected. Various primitives use caches that save context information. What is such primitive to do if the cache contains "beginning of nesting" outside of the current restriction, and the logic of said primitive says "go to the beginning of the current function and do such and such"? The answer isn't obvious to me. But it's going to need to be answered anyway, no matter which MMM approach we choose in the end, I think. > You mentioned some other problems, but never described them. What are > they? Are they grave enough to prevent your proposal from ever > supporting CC Mode, even if your proposal is amended? I don't know. > Does anyone know? If so, would they please speak up? Yes, please. > I also don't understand well the essence of your proposal. Yes, I've > (tried to) read the discussions you pointed to, but what I'm looking > for is buried there under many layers of secondary stuff. The proposal itself is very small, and there's not much to explain. Just look at the changes in the manual, in this branch. It simply facilitates what mmm-mode (and other modes, including mhtml-mode) has been doing for years, with varying success. And does that in a way that requires minimal changes from major modes (except for CC Mode, it seems), and would let us easily change our mind later. > Why do you > want to abandon the prog-widen stuff, which you supported just 2 years > ago? I never actually supported it, just stopped arguing because I didn't have a good alternative idea. Now I do, I think. And there is some agreement from Stefan. > How do you address the issues which prog-indentation-context did > (e.g., if the embedded chunk of code is incomplete, and perhaps even > syntactically invalid)? prog-indentation-context never addressed that issue, and we don't either. The major mode code in such situation will either have to swallow errors, or, well, they won't work. Or a MMM package will have to do error-swallowing, that's also possible. In practice, a lot of such situations don't actually manifest, though. > All these questions and considerations need > to be understood, because you are explicitly proposing an incomplete > solution, and asking us to agree with its deficiencies, but without > providing a clear picture of what are we going to give up on. That's the thing: we're not giving up much (I'd argue we're giving up nothing, but Alan obviously disagrees). Consolidating the 'widen' calls is simply good engineering, even aside from making life easier for MMM packages: it's much better to do that in several well-defined places, instead of having every helper function do it as well, like python-mode CC Mode do. > And > last, but not least, what is different in your proposal that will not > cause it to end up like all the previous ones: either committed to > Emacs and basically unused, or, worse, collecting dust in long > forgotten patches or branches? Like mentioned, the narrowing-based approach is already used in mmm-mode and mhtml-mode (and polymode too, I think). And it works fine in many situations, because many major modes already never call widen in their indentation functions (SMIE-based modes, Ruby, HTML and JS don't). So this proposal is, to a large extent, codifying an existing practice. And at the same time makes the aforementioned modes work *better* with interactive narrowing. > We desperately need these details spelled out to make the discussion > of this to become technical again, not emotional. Please feel free to ask any further questions. > You > are still debating its design and implementation, even if we disregard > the CC Mode issue. Not really. There's a minor issue of whether to make prog-first-column a variable, or a hook right away, but the importance of that choice isn't big. > That code is in Emacs for more than 2 years. It was admitted with > Stefan's full support, and at least ANTLR needs it in conjunction with > Python. Transitioning from prog-indentation-context to the new approach is very easy. And I would show you the patch, but unfortunately, the antlr-mode in Emacs doesn't use prog-indentation-context. So really, it's been here for 2 years, and virtually nobody's using it, or improving it. > Removing it without having some alternative again makes no > sense to me. You have the alternative, though. > We should discuss this when the incompatible code lands; How about we discuss it now? > at that time, we will see how to remove/replace prog-widen etc. with > minimal pain for its users. For now, there's no incompatibility that > requires us to remove the code. And anyway, making such changes when > we are in pretest is against our practices. That seems very unwise to me. Not to mention discouraging. Take a look at any third-party packages. I'm willing to bet none use prog-indentation-context yet. Maybe the standalone version of antlr-mode, if only.