I want to add some stuff to the completion DSL; opening this issue to allow others to comment before/while I implement it.

Currently there are a few things which can not be specified in the completion DSL:

• Different name/prefix in the completion popup than in the expansion.
• Whether or not to link placeholders together independent of equality of the initial replacement text.
• Which sort the placeholder is “equivalent” with. If this is available this would trigger the runtime to display all templates applying to that sort immediately when tabbing to that placeholder.

And some nice to haves:

• Multiple sorts per template (https://yellowgrass.org/issue/Spoofax/289)
• Multiple annos per template (for easier extension in the future)

And some things I don’t intend to cover for now (for completeness):

• Overriding the documentation in the documentation popup.
• Styling the string in the completion popup. (https://yellowgrass.org/issue/Spoofax/74)

So this is what I propose (where the [] indicate optional parts):

completion template: [Sort1[, Sort2[, Sort3]] =] [“trigger-prefix”,]
“first part” <displayed text[:Sort]> (cursor) “last part” [(blank)[ (linked)]]

The (linked) anno would mean link placeholders with identical text together. (Now this happens always, which I can’t really use…)

If this syntax seems decent and there are no better ideas then I’ll make it like this.

Submitted by Tobi Vollebregt on 20 April 2011 at 10:54

Looks good. Support for multiple candidate sorts and sorts for placeholders sound like a good idea. The "trigger-prefix" in your example would be the the name of the completion that is displayed in the menu? It would be good if the syntax for that was consistent with the syntax for refactoring specifications:

“refactoring” SemanticNode* “:” String “=” StrategoCall BuilderOption* -> SemanticRule {cons(“Refactoring”)}

That’s another cases where the old :/= convention didn’t really scale. The pattern matching ended up before the : and the name of the refactoring is after the :. Perhaps you can do the same here? Would be nice if backward compatibility was preserved by deprecating the old syntax.

Thanks.

The “trigger-prefix” in your example would be the the name of the completion that is displayed in the menu?

Yeah, displayed in the menu and used for filtering.

So the new proposal would be:

completion template: [Sort1[ Sort2[ Sort3]] : “trigger-prefix” =
“first part” <displayed text[:Sort]> (cursor) “last part” [(blank)[ (linked)]]

Note I removed commas between sorts too to be consistent with refactorings too.

Just wondering now whether the colon or the equals should go away if trigger-prefix isn’t specified :-)

Actually, in the refactoring syntax there’s no colon before the pattern syntax.

And it has been the convention in the esv language to use the colon if the middle part is omitted.

Ah missed that, thanks!

<displayed text[:Sort]> is breaking change, might need to introduce backward compatible syntax somehow. (and an escape in new syntax)

e.g. in Mobl:

completion template : Definition =
"import " some::module (blank)

Wasn’t this implemented already? Could you close it and tag it with a version number?

No, still need to address that compatibility breaking change (although I’ve no clue yet how; see previous comment), unless you agree that it is ok to have that breaking change.

(it is already in 1.0 as far as I know)

This feature is already implemented and I think it was first released with 1.0. This issue should really have been closed so that it was part of the changelog for 1.0, showing users that there was a (minor) compatibility-breaking change. The incompatible tag only only serves as a warning, we can’t always avoid it. (See the tag description.)

A new issue could perhaps be made for introducing escapes, but we can’t maintain full source-level compatibility here.