Spoofax has always hidden content completions for keywords like “(realtime)” until the non-identifier prefix (here, “(”) is typed in. Sebastian suggested changing this behavior, with at least the XML editor as a use case.

Right now the change seems to break content completion proposals for the SDF and ESV editor, that depend on it. It also breaks any generated keyword suggestions in other languages; “(realtime)” would be suggested everywhere. Therefore, I’ve rolled it back (r22914), at least for now, since we crucially depend on content completion in those editors…

Note that languages can specify what is considered an “identifier” in this context in the LANG-syntax.esv file. That may be usable to get syntactic content completions as desired in the XML editor.

Submitted by Lennart Kats on 18 May 2011 at 17:26

An adaption of my earlier proposal:
for every completion template, filter it out if the text between the current cursor position and the last whitespace is not a prefix of the template.

In contrast to the current implementation (as of r22914 again), this implementation relies on the notion of whitespace instead of identifiers. To me this seems more stable with respect to operators and the like (as in XML).

Also, why would (realtime) be suggested everywhere? Isn’t it bound to the BuilderOption sort?

Sort-based syntactic content completion was only added in a later stage. The SDF editor still uses the purely lexical content completion templates. Moreover, a number of editors, including the SDF editor and the ESV editor also use “keyword completions” in the Completions.generated.esv file that are purely lexical. Those completions are generated for literals in the grammar that do not start with an identifier character, such as (realtime) and \n and <Start>. Both the editors and the generator component were broken with the “22913” implementation.

Unfortunately, doing it based on preceding whitespace still breaks the SDF editor (which would suggest things like , avoid everywhere) and the generator component. And tbh, I’m fine with breaking the generator component, we can do better completions now using sort matching. It should just be disabled if we go back to the 22913 approach. The editors, though, should be updated before we change to that. We can’t just break the SDF editor. That will require some changes to the SDF editor definitions and a bit of testing, and we’ll have to find some time to do that. Other than that, I’m fine with 22913 as you proposed it.

I adapted the SDF completions for use in SugarJ (below are the ones I changed). Stratego and ESV completions were just fine. I did not check any generated completions, though.

completion template : Sdf2Attribute =
  "cons" "(\"" <Name> "\")"

completion template : Sdf2Attribute =
  "deprecated" "(\"" <explanation> "\")"

completion template : Sdf2Attribute =
  "reject"

completion template : Sdf2Attribute =
  "left"

completion template : Sdf2Attribute =
  "right"

completion template : Sdf2Attribute =
  "non-assoc"

completion template : Sdf2Attribute =
  "avoid"

completion template : Sdf2Attribute =
  "prefer"

completion template : Sdf2Attribute =
  "bracket"

completion template : Sdf2Attribute =
  "recover"

Looks good. And they work? Could you add them to the SDF editor?

Uploaded SDF completion templates with sort filter (r22921). Did not test SDF plug-in, but they work in SugarJ.

New approach (in branch): https://svn.strategoxt.org/websvn/StrategoXT/?rev=23570&sc=1

Got rid of all special cases, every proposal is handled identically, resulting in way cleaner code IMHO.

Blocking things before integrating this:

• Check/fix editors (I got fixes for editorservice editor)
• Better candidate sort detection (in editorservice editor the trunk algorithm doesn’t detect the *Anno sorts)
• Disable completion keyword generation

Sounds great! As for your blockers, did you find you had to change many things in editorservice? And did you check out the testing language? That one is also very sensitive to completion changes. For the second blocker, is that a problem? Or just a matter of changing some syntactic completion definitions? The third blocker shouldn’t be a problem, removing that stuff is fine.

I didn’t have to change much in the editorservice project: I just had to add the generated keywords starting with a “(” (FoldingAnno, BuilderOption, CompletionAnno and one CompletionPart) as completion templates with a sort.

Didn’t look at the testing language yet.

The second blocker can be worked around by specifying the sort it does come up with (SemanticRule) for the template. That means, however, that the keyword will be suggested in slightly too much places.