Some suggestions to improve the consistency of the EditorService language:

A) Consistency semantic nodes:

Many services can be specified on a Sort/Constructor combination, but
(according to the documentation) this is not consistent everywhere.

Folding, Outliner, Refactoring: .
Colorer: .,
Completions:
Reference Resolving:
Builders _

Improvement suggestion:
1) allow . in all cases (_ is a ‘match-all’, e.g. .C or S.),
2) interpret as Sort OR Constructor
3) add semantic nodes to builders

Remark:
- matching sorts in the reference resolving service seems logically, e.g. Id sort.
- I found a use case for matching constructors in the completion service,
namely when sorts are not found because the ast node is constructed in SDF.
For example, Shortcut and KeyCombination nodes in
“shortcut” “:” Id -> UIOption {ast(“Shortcut(KeyCombination(<1>))”), completion}

B) Consistency refactorings and builders:

• Refactorings can be defined on Sorts and/or Constructors. The specified Sort/Constructor determines
  which selected node is in the input term, e.g. “x”, Id(“x”) or Var(Id(“x”)), also, the refactoring is
  enabled in the menu if and only if the selected node matches the specified Sort and/or Constructor.
• Refactorings can be bind to a shortcut

refactoring .: …
shortcut: Shift + Alt + R

These features can be implemented for builders as well.

Submitted by Maartje on 16 October 2012 at 16:09

With respect to A) consistency semantic node, the behavior als seems to be different.
For example,
- refactorings: try hard to look for a node of the appropriate sort, e.g. “x”, Id(“x”), Var(Id(“x”)), Assign(Var(Id(“x”)), IntValue(“1”))
- reference resolving: pick selected node, for example Id(“x”), and hope it is the appropriate one.

Approach taken in refactorings seems the preferable approach here.

This sounds like a good idea. Some of the design was pretty organic. I like the approach of interpreting as the sort OR constructor, making it consistent everywhere and maintaining compatibility.