DevelopingBundles

See also Bundles.WhoDoesWhat and Bundles.HowToContribute.


Syntaxes

Naming Syntax Elements

Creating language grammar and the grammar syntax is described in the manual.

The following historical information describes the general idea behind the language element schema. Is this conceptual material still useful, or should we just delete all of this in favor of the manual?

Eric Hsu describes the scheme concisely:

I have my favorite color for different syntax items that I want to carry across different languages. So I separated items into different classes depending on whether I would want to color them in the same way. The assumption is format preferences for larger classes cascade down to the subclasses unless there are specific overrides.

Chris Thomas explains in detail:

There should be a minimum of top-level categories, and elements that are similar should be grouped together into similar categories. The names should not necessarily indicate the semantic of the element, because this scheme is primarily a tool to allow the user to change styles on similar elements as a group, while still permitting very fine-grained changes.

For example, instead of "keywords.methods", you almost certainly want "keywords.functions" so that function and method names are styled the same way across languages -- to be precise, functions are not the same construct as methods, but the distinction is irrelevant for this purpose -- if there's a need to distinguish visually, because the language has separate constructs for "methods" and "functions", use something like "keywords.functions.language-name.methods". Imagine the categories that a very simple user interface for changing highlight colors might have:

  • Language Keywords - keywords.*
  • Function/Method Names - keywords.functions.*
  • Variable Names - keywords.variables.*
  • Comments - comments.*
  • Embedded Documentation - comments.embedded-docs.*
  • Strings - strings.*
  • Regular Expressions - strings.regex.*
  • Literal Constants - constants.*

Two caveats:

  1. Not everything fits within these categories -- for example, this doesn't make much sense for diff output.
  2. None of this is set in stone. It may be, for example, that we don't want function names and variable names under "keywords.*". Happily, this sort of change can be automated (mostly). Feedback is welcome.