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

[Vladimir Panteleev <vladimir@thecybershadow.net>]

Hi Alan,

On Fri, 7 Feb 2020 at 21:31, Alan Mackenzie <acm@muc.de> 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.