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: Sun, 2 Feb 2020 16:59:43 +0000 Message-ID: References: <20200202115641.GA5547@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="28297"; 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 Sun Feb 02 18:58:14 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 1iyJVe-0007Fx-JB for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Feb 2020 18:58:14 +0100 Original-Received: from localhost ([::1]:58430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iyJVc-00035u-MP for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Feb 2020 12:58:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43936) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iyJVT-00035o-D5 for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2020 12:58:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iyJVR-0002Cj-TG for bug-gnu-emacs@gnu.org; Sun, 02 Feb 2020 12:58:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34526) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iyJVR-0002C5-Oz; Sun, 02 Feb 2020 12:58:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iyJVR-0002Cu-OH; Sun, 02 Feb 2020 12:58:01 -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: Sun, 02 Feb 2020 17:58: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.15806662298406 (code B ref 18158); Sun, 02 Feb 2020 17:58:01 +0000 Original-Received: (at 18158) by debbugs.gnu.org; 2 Feb 2020 17:57:09 +0000 Original-Received: from localhost ([127.0.0.1]:40499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iyJUb-0002BU-7e for submit@debbugs.gnu.org; Sun, 02 Feb 2020 12:57:09 -0500 Original-Received: from mail-lj1-f193.google.com ([209.85.208.193]:32811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iyIbN-0000dV-DK for 18158@debbugs.gnu.org; Sun, 02 Feb 2020 12:00:06 -0500 Original-Received: by mail-lj1-f193.google.com with SMTP id y6so12155401lji.0 for <18158@debbugs.gnu.org>; Sun, 02 Feb 2020 09:00:05 -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=Z1Hg5ncNx4r72vv1TXkv/H0rSfpQaVV6JarR6k80t3k=; b=peSV+LzIfdShBSv8uxj6xBZbsKnA6dq02eS9hEjuuBlBggWAi8sBP2rrBtYFe3rlXF pjR2xRYNNcWlg0VroYgsRJA3Ncs9utVTpAfwXqJGlykXldPflPdGbT+diRDL/ZuDLB3H gISjyIvbewQ7gZIOFeddWNpfSW4N5SK5prlNixFj9Do4l+6nLkv626Ej4HhNJCzmERmV exrZtwjuoGnchRxyXPrRghikYf4nlGRn+nS92hX77UZaeuRmfGfph9JYcGuyyucZ17jJ bTQfWN/T3TqwE/A3VofJv2LTV/uMQuoAEdl9QznABsxK/hWnLKdJa105gb68Wf6cyEgS veFw== X-Gm-Message-State: APjAAAUNCJkKX5G5vr16gzKgUs/jfjUjgVB4D5OtyldtB6yx1JE73JF2 J87ImoSpuEBEyWpmaSrUR948jjN0m9dXO/cT4c4= X-Google-Smtp-Source: APXvYqyuMm/nyYtN43l+HOAb+XDXv0Niug5eal5Epwk27ldLFRGKnDbPbwalxP4zyAL0YLr2EISycFx0A7l9ZXT9Eug= X-Received: by 2002:a2e:918c:: with SMTP id f12mr10659163ljg.66.1580662799424; Sun, 02 Feb 2020 08:59:59 -0800 (PST) In-Reply-To: <20200202115641.GA5547@ACM> X-Mailman-Approved-At: Sun, 02 Feb 2020 12:57:07 -0500 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:175601 Archived-At: Hello Alan, First, thank you very much for reaching out. I held the expectation that the maintainer(s) of cc-mode would not have any time to spare on derivative modes distributed outside of Emacs, so your message was a welcome surprise. I greatly appreciate you taking the time to prepare a patch for d-mode. However, I hope you will forgive me if I burden you with a bigger matter. As of last year, I had been working on a major update to d-mode. This new version fixes all known bugs in d-mode filed so far and has many other improvements. It is located here: GitHub pull request: https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode/pull/93 Git clone URL: https://github.com/CyberShadow/Emacs-D-Mode.git ("next" branch) Current version: https://raw.githubusercontent.com/CyberShadow/Emacs-D-Mode/next/d-mode.el I'll be happy to create non-GitHub mirrors of the above upon request. Unfortunately, the only way I found to achieve these improvements in D language support was through advising even more cc-mode functions, similar to the "looking-at" advice your message pertains to. I fully realize that this approach is not very future-proof. I tried to keep the implementation as unintrusive and unreliant on cc-mode internals as possible. However, cc-mode is a non-trivially large and complicated piece of software, and D is a relatively large and complicated language, so I admit I have likely fallen short of that goal. My plan for ongoing maintenance was to keep up and address problems due to changes in cc-mode internals as they occur; however, considering the amount of time required to debug and devise fixes for each problem, I may have been overly eager in considering this approach. For this reason I had been thinking of contacting you for advice on how best to proceed. Some possible ideas I had in mind: 1. Add hooks and variables to cc-mode to allow d-mode to cleanly configure cc-mode to support the D language. Though I believe D firmly fits into the Algol-like family of languages currently supported by cc-mode, it also has many unique features, so I worry that this approach would be overly burdensome to cc-mode. 2. Move d-mode into cc-mode, replacing advice hacks with clean integration. I would be happy to contribute my work to GNU and continue supporting d-mode within cc-mode, if this is a possibility. However, even though most of the code in my "next" branch was written by me, the project has been around for a while, and I don't know if we can find all authors and have them transfer copyright to FSF; or, alternatively, move only the code I've written, and rewrite the missing parts, but I don't know how strict we would need to be in this regard. 3. Reimplement d-mode in cc-mode. It might be easier to start from scratch and, using just the existing d-mode test suite for reference, reimplement d-mode within cc-mode. Not having to resort to hacks such as advising functions will likely allow a much cleaner implementation than the current one. 4. Copy relevant parts of cc-mode into d-mode. One very ugly, but possibly practical approach would be to include all relevant cc-mode code in d-mode's distribution. All definitions would need to be properly namespaced to not conflict with the real cc-mode. This would effectively "freeze" the cc-mode version that d-mode uses, thus protecting it from incompatible changes in internals of future cc-mode versions, though compatibility fixes for future Emacs versions would still need to be applied, and d-mode will be unable to benefit from any future cc-mode improvements. 5. Abandon ship, and scale back D language support in d-mode to a maintainable minimum. Perhaps using cc-mode for D language support within Emacs is not an optimal solution. All of the above ideas would certainly require a non-trivial amount of further effort to achieve, and the result would only cover the combination of supporting the D language within Emacs. An approach that has been recently gaining popularity is, instead of writing one package for each language for each editor, to use "language servers" which use a common protocol to provide language support to any editor. The LSP protocol specification (as maintained by Microsoft) supports formatting (indentation), outlining (imenu), and (in recent versions) semantic syntax highlighting (fontification), with the downside of requiring additional software and configuration. If there is no interest in supporting D / d-mode in cc-mode (ideas 1-3 above), then perhaps this may be the best course of action. I would love to hear your thoughts on the above. Also, looking at the email headers, I see that this message was in reference to Emacs bug 18158. Looking at the previous messages in the bug thread (https://debbugs.gnu.org/18158), I found it odd that a bug in d-mode's behavior was filed at Emacs' bug tracker. I think that any d-mode or cc-mode issues observed when d-mode is active ought to be reported to the d-mode bugtracker, and not the cc-mode one. It is certainly not my intention to burden cc-mode maintainers with d-mode's bugs or shortcomings. Perhaps there is something I need to do to make it clearer where to report bugs in d-mode? In any case, I've been unable to reproduce the bug (as it was originally filed, and with the test code provided in message #20 (<8B3ABB9B-7A39-428A-A65B-B77D0614C9FE@gmail.com>), on either the current master branch or my "next" branch of d-mode. I see that the bug was filed in 2014. Perhaps it was fixed by this commit in 2015: https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode/commit/27fbe66f6de27f8337fe40d6a19f039c589cd1fc I added a test case for this fix in this commit: https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode/commit/3e5a5d523d7580b2a42f376cbf83bdd9ac296bbd Best regards.