From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Vladimir Panteleev Newsgroups: gmane.emacs.bugs Subject: bug#18158: D Mode: Getting rid of the ugly advice on looking-at. Date: Thu, 13 Feb 2020 13:37:19 +0000 Message-ID: References: <20200202115641.GA5547@ACM> <20200207213100.GB8591@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="19219"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 18158@debbugs.gnu.org, stefan@marxist.se, russel@winder.org.uk, liranz@gmail.com To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 13 14:38:20 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j2Eh8-0004rl-5j for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Feb 2020 14:38:18 +0100 Original-Received: from localhost ([::1]:52418 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2Eh7-0001sb-65 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Feb 2020 08:38:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48888) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2Egt-0001mf-MA for bug-gnu-emacs@gnu.org; Thu, 13 Feb 2020 08:38:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2Egs-0005q9-7a for bug-gnu-emacs@gnu.org; Thu, 13 Feb 2020 08:38:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53451) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j2Egs-0005q1-3B; Thu, 13 Feb 2020 08:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j2Egs-0005KJ-1e; Thu, 13 Feb 2020 08:38:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Vladimir Panteleev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 13 Feb 2020 13:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18158 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: moreinfo X-Debbugs-Original-Cc: bug-cc-mode@gnu.org, 18158@debbugs.gnu.org, Stefan Kangas , Russel Winder , Liran Zvibel Original-Received: via spool by 18158-submit@debbugs.gnu.org id=B18158.158160106320451 (code B ref 18158); Thu, 13 Feb 2020 13:38:01 +0000 Original-Received: (at 18158) by debbugs.gnu.org; 13 Feb 2020 13:37:43 +0000 Original-Received: from localhost ([127.0.0.1]:59424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j2EgZ-0005Jn-0m for submit@debbugs.gnu.org; Thu, 13 Feb 2020 08:37:43 -0500 Original-Received: from mail-lf1-f68.google.com ([209.85.167.68]:36683) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j2EgX-0005Jb-Sx for 18158@debbugs.gnu.org; Thu, 13 Feb 2020 08:37:42 -0500 Original-Received: by mail-lf1-f68.google.com with SMTP id f24so4298856lfh.3 for <18158@debbugs.gnu.org>; Thu, 13 Feb 2020 05:37:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xaMG12MoLo9DUwe29xtiYprXPJhKk6q/hem7DlP3ya4=; b=prsA0+qqtcLjZdKh8Xh7iEQe/yt2P+var9f0PHfgcDw+e7jth37sza52B+bH5PIupN TzUg0KdWn8ltfEr1itHEMXrDlxP/I2355f2BAqUTdnqzlIIVvZvcCiaNVhhCa+SOcu7Y uRFY0YbvTMd7IgqUfPSbQHFi5WviGzPLTMyeyydUyIs3I+kMmzYOj/a9jZU3xs80b7H9 H51ZX9dsS72tBE4pdu7AR9O1EX6zY9hnIUQin7VOKeHST0IRlANccemrNVg6TG9W4F3+ FB5L5zVbNOsI10TqT3hINfPGkwXSbNsBE9xd8cvmzsyVQRPNd7HpgFtPNeRKi6bZ9Nps ob5w== X-Gm-Message-State: APjAAAVz3v0ONhOyX3R41b7zHFJAojM2LS7SMdgX9mSNtqcB1arVPoz8 ogbC257xz5FNyN4AkmFvQlqWzvThFiBvtbNk1b0= X-Google-Smtp-Source: APXvYqxM7WGAbq/krkXebkFCAp09yTtlGvVXr3UTj2HMcmnpKmwUaLoEgESF91XOXtWj3i8BRTbHObuaGOcFLdjNlFU= X-Received: by 2002:ac2:5626:: with SMTP id b6mr1033701lff.134.1581601055961; Thu, 13 Feb 2020 05:37:35 -0800 (PST) In-Reply-To: <20200207213100.GB8591@ACM> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:175994 Archived-At: Hi Alan, On Fri, 7 Feb 2020 at 21:31, Alan Mackenzie wrote:> > Unfortunately, the only way I found to achieve these improvements in D > Could you possibly give me one or two examples of why these pieces of > advice are needed? This would give me more of a feel for what the > problems are. Yes, gladly. d-mode installs advice in seven^Wsix places, all of which are in cc-mode. Here is a rough / brief description of each. 1. The looking-at call from within c-add-stmt-syntax which started this discussion. It has been later extended in 075c3e7b8da8bfffe1bbe00cf705494755959fd1 to also apply to "version" and "debug" blocks. 2. A replacement of c-forward-decl-or-cast-1. The D version, which is an edited copy of the cc-mode function, has additional code required to recognize and fontify variable declarations in foreach statements and lambda expressions, as well as conditional compilation. The D version (d-forward-decl-or-cast-1) completely replaces c-forward-decl-or-cast-1, and only a small part of the original remains. 3. A replacement of c-get-fontification-context. This one is also used for foreach loops and lambda parameter lists. I'm not sure the "integration" with cc-mode is that great here - the code might be using some constants with different conventions than cc-mode. 4. A replacement of c-in-knr-argdecl. Here d-mode abuses cc-mode's logic for two features that are syntactically a bit similar to K&R C argument lists - function contracts and template constraints. They also exist between the function signature and its body, so making use of the existing K&R mechanics in cc-mode seemed like the simplest way to fix support for these constructs. 5. A replacement of c-forward-type. This one also implements only exactly the syntax in the D programming language. 6. A modified version of c-update-brace-stack. The modifications were necessary to help cc-mode understand static compilation constructs in the D language. Syntax such as "static if" does not change whether its substatements are "top-level" or not, and it can be used with or without a { } pair, which required custom logic. As I was making this list, I couldn't remember what one of the advice was for, so I removed it - and the test suite still passed, so it seems like my newer changes made it obsolete. I committed the removal. > How does D compare with C++ in terms of complexity? I would say D is definitely less complicated than C++, and it's especially easier to parse (it was designed from the beginning to avoid pitfalls such as the ambiguity of "a < b, c > d"). However, it also has many features (for instance, depending on how you count, it has about seven kinds of string literals). Some troublesome aspects I ran into while working on d-mode were type inference (types may sometimes be omitted from declarations) and parameter lists ("(a, b, c)" is a list of types for a function declaration, like in C, but a parameter name list with inferred types for lambdas). > One practical step for option 1 would be for you to have write access to > the CC Mode repository, in particular to a "D Mode" branch, where you > could implement the necessary CC Mode features to support D Mode. > Something like this was done ~10 years ago for enhancing Java Mode. That would work; though, I might need a bit of guidance with making my cc-mode modifications acceptable :) E.g., what would be a good way for derived modes to replace cc-mode functions such as c-forward-type. > But perhaps a D Mode support file could be included in CC Mode, somewhat > along the lines of how cc-awk.el supports AWK, but including only > essential support for D Mode rather than including D Mode itself. I'm > not sure if I've explained that very well. I think I understand. Probably it will be clearer which way is best once we attempt to do so. > > I would love to hear your thoughts on the above. > > I hope I've given you enought to think about. ;-) Indeed. Thank you for the extensive reply. I agree with and have no further comments on everything you said not quoted above. > To reproduce it, I temporarily removed the advice on `looking-at' from D > Mode. The problem was then apparent in the test code supplied by Liran > Zvibel on 28th January to me, Cc: to the Emacs bug list. Oh, I see. Thank you for the clarification. I guess I could have put two and two together :) Best regards.