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 19:43:31 +0000 Message-ID: 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> <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> <83k1y3zq2n.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 1512330233 32326 195.159.176.226 (3 Dec 2017 19:43:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 19:43:53 +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 20:43:47 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 1eLaAy-00080O-5J for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 20:43:44 +0100 Original-Received: from localhost ([::1]:39991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLaB5-0008Ok-HX for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 14:43:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLaAx-0008OO-Go for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:43:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLaAs-00086A-HC for emacs-devel@gnu.org; Sun, 03 Dec 2017 14:43:43 -0500 Original-Received: from mail-lf0-x243.google.com ([2a00:1450:4010:c07::243]:34929) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLaAs-00085p-4C; Sun, 03 Dec 2017 14:43:38 -0500 Original-Received: by mail-lf0-x243.google.com with SMTP id j124so16849113lfg.2; Sun, 03 Dec 2017 11:43:37 -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=r2Uwd7B3HS/TSN+vO1oE2HVqAd+cR+XnxQ75hI7EPkk=; b=fH6DLR6HrVXJMiSq42f6NuDJF0mDDs5Rex8nBZXWD8OoiXYGoxU3zAVB12RtsAnD8i 2QKq7psIzbfmtcxVbHQiBuy2NO7hY7DfBz05yAkUKz5YUMXJYiR5CH3+LgjlVvKYJNwr ixorJm3kpeHNTdQYeEOiU1aCG+3UJ3MzIEpV2LDuUFIJSEWyoGbk0XrheM5TT9jlRZ9b HfjpzS3i/SPsxG54vzI6w4reXopdJrVfuGB8AxPz/3pAyUcLTI3TJ0aJVbVUkV6KHWK+ x9ojzxjSDFWt9Q/rB7D8eQ7R2XZwb7I8ZUxQOCh1f5/VnEkDEt0qJdB0mieGdlDaaftq uSzg== 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=r2Uwd7B3HS/TSN+vO1oE2HVqAd+cR+XnxQ75hI7EPkk=; b=b/9USTWM4NrZ0auUpnahVwdzuSGNzSoP1IHL7YDqHxuJD7HuJ0BgF7qLlyIPmziKL3 DDzRMBnwPZpFhYXPqISIc4sg4vHWixeCnZJv/kmkHvheuN7DwKLYdmUkKiI5PbWVfboB 1CC1F7UQzrNRQhFaJhcnUtIObr7TikAcYMfrMen5n3r1PhXBR0T+OGqj4Gs70z/fbeCL 8RGZCR43m5RFLhYNkIHi1QvAiwPIYupo65QDPmHATCzAGxyP2TwKYfuyPjRYcS9l6D/a kpME7sj+SKi50sABIl3es1Ac7SmjreqQmXeFzDq6aO+UrM9j1fbtGSdg448/GjvGXixo 7zUg== X-Gm-Message-State: AJaThX5cXPaCpDKFDSFVDOERpjG//Sr9J8SBIm/g0jM+XnRm9Y1db3YY 25bczwBldaQWsAdnQIOtykOAFyem8Tw= X-Google-Smtp-Source: AGs4zMZEuCBtr83tKi6u8v1pTduX5B8JBBeub+V9dC/dnTHqXmF96A1pZx0jIOhopxL5LS2heKzJaQ== X-Received: by 10.25.151.209 with SMTP id z200mr6110568lfd.153.1512330216186; Sun, 03 Dec 2017 11:43:36 -0800 (PST) Original-Received: from [10.11.133.196] ([217.153.136.0]) by smtp.googlemail.com with ESMTPSA id z81sm2051179lff.80.2017.12.03.11.43.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Dec 2017 11:43:35 -0800 (PST) In-Reply-To: <83k1y3zq2n.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::243 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:220660 Archived-At: On 12/3/17 5:20 PM, Eli Zaretskii wrote: >> This feature is *not* targeted at Emacs development. > > It is for me. You are not working on it. You've expressed no interest in this problem until now. Maybe delegate the basic requirements, at least, to the people who did? >>> Indeed; and C-like languages are quite popular among them. >> >> Not in comparison to JS, CSS and HTML. > > Maybe in your world, but not in mine. So we will have to agree (or > disagree, if you want) that both worlds need to be catered to. Yes, and they can be catered to, *as soon as* the authors of each individual major mode make the effort to support the feature. Having it work in HTML, CSS, JS and Ruby is in no way dependent in investigating and fixing the behemoth that CC Mode is. >>> 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. > > From your POV, maybe. Not from mine. Eli, we already have a feature in Emacs (prog-indentation-context) that does not adhere to your (unreasonably high) requirements. Let's at least take it out, then. >>> Convince Alan to do what? >> >> To adhere to the current proposal (avoid widening in >> indent-line-function and font-lock-keywords, to start with). > > We need to understand the full extent of problems, and then we need to > see how to go about them, at least design-wise. "To start with" is a > start, but it cannot be the middle and the end. The full extent of the problem can be realized as one tried to do what I said, step by step. And see what else can be is going wrong. > If he agrees, that'd be swell. If not, I see no reason why someone > else couldn't do that and report back, it's not like CC Mode is hard > to activate and see what problems pop up. Please go ahead and do it, then. If you're really expecting me to do it, it's unrealistic. Getting oriented in CC Mode will take days, if not weeks. And I have no interest nor energy to do that. >> 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. > > How about describing what you do know? Already did. Last time I tried investigating it was 1-2 years ago, and at no point I felt I reached an understanding of why CC Mode exhibits the problems it does, or what I could change to fix them. So all I have are vague recollections. >> 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. > > I don't understand: AFAIU in the use cases supported by MMM there can > be nothing outside of the current restriction that is of interest for > the mode which supports the chunk under the restriction. So what kind > of "nesting outside of the current restriction" are we talking about, > and how does it come into play? Imagine if the chunk contains only this: < And, to fontify it, CC Mode, tried to find out what syntactic element it is, and to do that, calls some function that uses a specialized cache that's contained in a variable that mmm-mode knows nothing about. And that cache point to a position outside of the current restriction. Confusion ensues. I've seen errors originating from that (I think), but can't recall the exact sequence of calls. >> The proposal itself is very small, and there's not much to explain. Just >> look at the changes in the manual, in this branch. > > That just removes text, more or less, and what it adds doesn't explain > itself well enough, sorry. Otherwise I wouldn't have asked these > questions, believe me. The text it adds is more important. Including the mentions of font-lock-keywords and syntax-propertize-function, by the way. >> It simply facilitates what mmm-mode (and other modes, including >> mhtml-mode) has been doing for years, with varying success. > > Sorry, that doesn't help me understand the proposal, as I don't know > mmm-mode well enough. How hard is it to just describe the idea in a > few sentences? Not really sure what to describe. To fontify (or indent) a chunk, mmm-mode narrows to its bounds, and calls the corresponding indent-line-function (or applies font-lock-keywords). If either of those calls (widen), that causes problems. So we want to document a convention that they don't call widen. That's really it. >> 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. > > (whose change of hearts is also a mystery for me) Sometimes a better technical proposal does that. For more context: we're been waiting for some kind of improvement for this problem for years. Then prog-indentation-context came along, and it wasn't terrible (though it didn't solve all of the problems we wanted). That seemed a good enough reason to adopt it, to some of us. Since then, for the mentioned two years, the original author contributed no improvements aside from the mentioned support in python-mode, and no other mode added support for it, or used it, inside or outside Emacs. So it seems to me like it pretty much failed. >>> 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. > > I think it does, at least to some extent. Not any more than scratch/widen-less. > And even if I'm wrong, then > what is the equivalent of what it does address in your proposal? There are full equivalents. We keep 'prog-first-column' from that proposal, 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. > In any case, we should at least have provisions for supporting that > within the proposed framework, and we should be fairly certain that > supporting that later will not blow things up. I have honestly no idea where to begin in addressing that issue. On the other hand, there are third-party MMM framework that function within these limitations, and are helpful to users. >> That's the thing: we're not giving up much > > For the modes that are dear to your heart, maybe. But that's not all > Emacs should support well, IMO. For all modes. The user won't lose any functionality, at all. Even if the programmer might have to spend some effort for that to happen, for some of the modes. > The 'widen' thing is a non-issue; it's the other stuff I'm worried > about, mostly because it is left unsaid, undiscussed, and I fear > uncatered-to by the design. What other stuff? We basically say "widen happens in one place, don't do that again", and that's it. >> 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. > > The fact is, it isn't done yet, let alone well-tested. It can be "done" in a day or two. >>> 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. > > 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. Why confuse the language modes authors? >> So really, it's been here for 2 years, and virtually nobody's using it, >> or improving it. > > It's definitely used by its author, so "nobody uses it" is untrue, and > even unfair: that feature was accepted by Stefan, under the assumption > that it will be used. ...and improved, and support for CC Mode would be contributed. Which it wasn't. The author, who's the only user of prog-indentation-context, can transition to the new convention trivially. >>> Removing it without having some alternative again makes no >>> sense to me. >> >> You have the alternative, though. > > No, we don't. You are asking to remove the code _before_ the > alternative lands. You have the choice of accepting the alternative sooner, though. >>> We should discuss this when the incompatible code lands; >> >> How about we discuss it now? > > The incompatible code didn't land yet. But feel free to include the > replacement in your branch. It's in there already. >> Take a look at any third-party packages. I'm willing to bet none use >> prog-indentation-context yet. > > We cannot know that. Once the code is that long with us, we cannot > throw it away without a equivalent replacement. And I see no reason > to do that now, since the fact that this code will exist in Emacs 26 > doesn't hurt anyone, especially since the replacement will be easy, as > you say. Well... you have a point there. The result will be pretty ugly, though. Adding an API in one version, and removing it in another. They are incompatible with each other, so it's not like there can be a smooth transition.