bug#18158: D Mode: Getting rid of the ugly advice on looking-at.

[Vladimir Panteleev]

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.