D Limitations

Fontification

• An ampersand as the last character in a string or before a backslash-escaped double quote in a string prevents this double quote from being recognized as a string delimiter. Workaround: Write [&&] or "\&" instead of "&".

• A backslash character token &\\ immediately followed by a lowercase letter is misinterpreted as a directive, e. g., in C == &\\andthen ... Workaround: Include a space character.

• At maximum fontification level, method names are coloured in font-lock-funtion-name-face. If one mistakenly uses a keyword as method name, as in meth lock() ... end, then one is not reminded of the fact that this constitutes a syntax error.

• The use of non-escaped double quotes in Gump regular expression tokens written with angle brackets confuses fontification. Workaround: Express the regular expression by a string.

Indentation

• If a keyword is immediately preceded by a number (without space), e. g., 10thread, the keyword is not recognized as such. This also concerns fontification. Workaround: Write a space.

• Indentation does not know about /* ... */ style comments, that is, their contents is indented like code and taken into account for computing the following indentation level. Workaround: Only use such comments to comment out properly nested code.

• Indentation does not know about conditional compilation. Workaround: Only use conditionals around properly nested code.

• Line breaks inside strings, quotes or backquote variables are reported as errors when computing the indentation level. Workaround: Write line breaks as "\n" and/or use virtual strings with # concatenation for multiline strings.

• Indentation is not aware of infix operators, e. g.:

  feat 
   f:
      5 + 
   7

  The 7 should be underneath the 5. Workaround: Enclose the expression in parentheses.

• The contents of Gump regular expression tokens in angle bracket notation are not ignored for purposes of indentation. Workaround: Express the regular expression by a string.