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: Mon, 04 Dec 2017 17:52:26 +0200 Message-ID: <83tvx6xzgl.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> <83k1y3zq2n.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512402810 12356 195.159.176.226 (4 Dec 2017 15:53:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 15:53:30 +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 Mon Dec 04 16:53:25 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 1eLt3b-0002sX-Mw for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 16:53:24 +0100 Original-Received: from localhost ([::1]:43826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLt3j-00030i-4U for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 10:53:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLt2w-0002vk-0R for emacs-devel@gnu.org; Mon, 04 Dec 2017 10:52:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLt2t-0005LD-CL for emacs-devel@gnu.org; Mon, 04 Dec 2017 10:52:42 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLt2t-0005L4-8I; Mon, 04 Dec 2017 10:52:39 -0500 Original-Received: from [176.228.60.248] (port=4284 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLt2s-00064W-9X; Mon, 04 Dec 2017 10:52:38 -0500 In-reply-to: (message from Dmitry Gutov on Sun, 3 Dec 2017 19:43:31 +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:220697 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 19:43:31 +0000 > > 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? Your work on this is highly appreciated. But I have certain responsibilities, and I'm trying to do my job here. I'm also your fellow developer of the same project and its active user. I think it means my opinions should be of some importance, not something to be ignored solely because I'm not coding this. Just like I would never dream of ignoring your opinions about features I'm implementing. As for expressing interest: you are mistaken when you judge that by my silence -- it only means that I had nothing significant to say about the issue, until I did. > [C-like major modes] can be catered to, *as soon as* the authors of each individual major mode make the effort to support the feature. Agreed. What I'm trying to establish is whether the design supports those major modes, or does it ignore them. The latter I would like to avoid as much as possible. > Eli, we already have a feature in Emacs (prog-indentation-context) that does not adhere to your (unreasonably high) requirements. Emacs development is not only about not losing existing features. It is mainly about gaining new important features. Here you are adding a feature that I think is important enough for us to try make it support C-like languages. I don't think this requirement is unreasonably high, as those languages are still pretty much the mainstay of the industry, and definitely used by many Emacs users. > 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. Thanks, so the caches will have to be sensitive to restrictions as they are sensitive to deletion of text. > 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. But given your example with CC Mode's caches, that's not all of it, is it? You also need the mode to adapt any such caches to changes in buffer restrictions, right? > 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. Maybe I'm missing something, but what's the equivalent of PREV-CHUNK? > We keep 'prog-first-column' from that proposal But it was a function, and you made it a variable. This will get in the way of compatibility, and also potentially will make future extensions harder. Why not keep it a function? > 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. This simplification also took away some of the features, like the ability to nest restrictions. I wonder why did you discard that. It's existing functionality, pretty lightweight, which was in Emacs for some time, and is reasonably well documented. And it already satisfied your requirement of not allowing sub-modes to widen. Why not leave it alone? What am I missing? > 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? If they should be confused (I don't think so), they are already confused, as we've been having this for the last 2 years. > 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. We will have to discuss the "removal" part. An alternative is to provide compatibility shims, or even leave (some or all of) the existing API intact. > They are incompatible with each other, so it's not like there can be a smooth transition. I don't see the incompatibilities. Basically, you replaced prog-widen with widen, made prog-first-column a variable instead of a function, and tossed prog-indentation-context. We could instead keep the existing API with minimal changes: prog-widen calls widen internally, and we could allow direct calls to widen as well. IOW, the transition could be much smoother than it will be if we actually remove that stuff, because I don't think there's any incompatibility here which would disallow direct calls to 'widen' and/or leaving prog-indentation-context at its default nil value. Or maybe I'm missing something again. But if I'm right, and if we can make the necessary changes limited only to the documentation, then it could well make it into Emacs 26. So I think it is worth our while to make some effort in that direction, if at all possible. Thanks.