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 17:28:48 +0200 Message-ID: <83mv2zzv7z.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512314990 363 195.159.176.226 (3 Dec 2017 15:29:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 15:29:50 +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 16:29:44 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 1eLWD8-00085F-7T for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 16:29:42 +0100 Original-Received: from localhost ([::1]:39281 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLWDF-0000xM-Ga for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 10:29:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLWCa-0000q8-7G for emacs-devel@gnu.org; Sun, 03 Dec 2017 10:29:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLWCW-0002tU-C7 for emacs-devel@gnu.org; Sun, 03 Dec 2017 10:29:08 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLWCW-0002tP-7V; Sun, 03 Dec 2017 10:29:04 -0500 Original-Received: from [176.228.60.248] (port=2963 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLWCV-0006da-KH; Sun, 03 Dec 2017 10:29:04 -0500 In-reply-to: (message from Dmitry Gutov on Sat, 2 Dec 2017 21:35:43 +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:220652 Archived-At: > Cc: acm@muc.de, tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 2 Dec 2017 21:35:43 +0000 > > I'm asking why "Emacs is written in these 2 languages" is important. Because every development environment should first support its own development well. If it doesn't do that, it's incomplete. > > Surely, a feature that aims to > > support multiple major modes should strive to support CC Mode? > > Not necessarily. It should first and foremost support the languages that > are most important for our users. Indeed; and C-like languages are quite popular among them. 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. > > They are important, but so are C-based languages: C++, Java, Awk, etc. > > I don't know CC Mode, and cannot provide patches for us. I tried > debugging related problems a few times, and those turned out to be > fairly long spelunking expeditions. > > However long it will take just to convince Alan to agree, is anybody's > guess. Convince Alan to do what? Do we even understand well enough what are the problems in CC Mode that get in the way? 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). But is that all? 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? 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. Why do you want to abandon the prog-widen stuff, which you supported just 2 years ago? 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)? 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. 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? We desperately need these details spelled out to make the discussion of this to become technical again, not emotional. > > It's not a catastrophe. Assuming Emacs 26.1 is not a complete > > disaster, we could decide releasing Emacs 27.1 as the next version. > > Not a catastrophe indeed. But no step forward for mixed-modes support in > Emacs 26 would be unfortunate. Emacs 26 has enough new features to justify a major release, so I see no reason to press so hard to get this feature into it as well. You are still debating its design and implementation, even if we disregard the CC Mode issue. It makes no sense to put this into a code base which is frozen since September. > > Why would we need to remove that for Emacs 26.1? > > It's not well supported, and it's incompatible with the code we are > discussing. There's no point in having it present in Emacs 26, and then > removing it in Emacs 27. 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. Removing it without having some alternative again makes no sense to me. We should discuss this when the incompatible code lands; 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.