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: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 03 Dec 2017 19:20:00 +0200 Message-ID: <83k1y3zq2n.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512321638 29183 195.159.176.226 (3 Dec 2017 17:20:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 17:20:38 +0000 (UTC) Cc: acm@muc.de, tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 18:20:32 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 1eLXwH-0006t4-Ok for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 18:20:25 +0100 Original-Received: from localhost ([::1]:39671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLXwP-0002Wd-3L for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 12:20:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLXwI-0002WX-IP for emacs-devel@gnu.org; Sun, 03 Dec 2017 12:20:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLXwF-0006Ub-AX for emacs-devel@gnu.org; Sun, 03 Dec 2017 12:20:26 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLXwF-0006UQ-1v; Sun, 03 Dec 2017 12:20:23 -0500 Original-Received: from [176.228.60.248] (port=3281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLXwD-0001nu-Hq; Sun, 03 Dec 2017 12:20:22 -0500 In-reply-to: <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> (message from Dmitry Gutov on Sun, 3 Dec 2017 16:35:23 +0000) 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:220656 Archived-At: > Cc: acm@muc.de, tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 3 Dec 2017 16:35:23 +0000 > > This feature is *not* targeted at Emacs development. It is for me. > > 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. > > 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. > > 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. > > 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. 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. > 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? > 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? > 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. > 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? > > 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. (whose change of hearts is also a mystery for me) > > 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. And even if I'm wrong, then what is the equivalent of what it does address in your proposal? 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. > > 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 For the modes that are dear to your heart, maybe. But that's not all Emacs should support well, IMO. > 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. 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. > > 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. The fact is, it isn't done yet, let alone well-tested. > > 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. > 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. > > 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. > > 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. > > 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. I don't see anything unwise in it, let alone discouraging. We've turned down much simpler and safer changes that came too late, and no one claimed that was unwise or discouraging. > 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.