Initial Version: Challanges for an editor / multimeta model example

[goto40]

Here, we have an inital version of some example DSLs. Details/challanges: see examples/multimetamodel/README.md: The goal is

• to show how to setup textX DSL projects (focus: multi metamodels), and
• to show how to integrate textX DSLs into textX-LS.

Note: at the moment no language template or similar has been applied. I am willing to change this, but I like to get some first feedback, the I can adapt according to comments.

Comments welcome! (Commit history is a mess; we can squash all commits into one when merging).

[goto40]

Migrated comments:
Here are some notes (we can continue in the new repo afterwards):

• I would like for validate... CLI commands to be registered as textX CLI extensions textx validate .... If made generic enough validate subcommand might move to the textX project and specific validators could be registered at a new entry point analyzed by validate subcommand.
• I like challenges for an editor sections. Those should help @danixeee to test LS and VS Code extensions. After that work is finished we could update those sections to explain how LS and the editor supports those features.

[goto40]

Added issue to changes the "challanges" sections later.

[goto40]

I have added a click toolset for the 01_separate_projects-example (see README.md).

I have not (or not yet) integrated validate into textx. I am uncertain about that: how to identify the DSL from a generic validate command, other than via the file extension. In the 01_separate_projects-example I have solved this problem by overloading the validate command three times (+using the MultiMetaModelProvider).

Other ideas welcome about how to integrate with click or the textx main command.

Is the usecase of having a dedicated compiler for a DSL or a set of DSLs (e.g., "types_data_flow_dslc" see README.md) not exactly what you expect from a DSL?

[danixeee]

@goto40 I went through this example and with the current implementation, I see two ways of how we can use language template to create support for textX-LS:

• multiple python packages with one language template in each of them

  types language setup.py

  entry_points={
       'textxls_langs': [
           'type = textx_ls_type:TypeLang'
       ]
   }

  flow language setup.py

  entry_points={
       'textxls_langs': [
           'flow = textx_ls_flow:FlowLang'
       ]
   }

• one python package with multiple language templates

  type AND flow language setup.py

  entry_points={
       'textxls_langs': [
           'type = textx_ls_type:TypeLang',
           'flow = textx_ls_flow:FlowLang'
       ]
   }

Unless I overlooked something, we are pretty flexible with this approach.

We will still have to address non-textX models, but at this time I am not sure if that has to be part of textX-LS or textX itself.
Note that I have already added language server support to textX project, but it needs to be revisited, because that was before scoping.

[goto40]

I need to take a look. Can you give a hint, where, e.g., textx_ls_type resides? I assume I need to provide a class.

For the textx integration:

• at the moment scope providers only search for one exact match of a reference name. Thus, the editor cannot propose a list of potential elements, but only validate a given reference name.
• We could extend the interface easily to allow retrieving a list of reference names matching a given substring...

[danixeee]

textx_ls_type is just a name of python package (project).

You can take a look at this example. You have to provide a class (language template) for each language that you want to register via entry points.

[igordejanovic]

@goto40 I started with the review but realized it would be easier and faster for you to just merge this to master and than we'll work on changes as another PRs. I would have some suggestions but it might be easier for me to just do the changes.

I think I'll do another round of textX API cleanup/documentation before going 2.0. It would be nice to make this example ready and in sync with those changes for 2.0 release :)

Tip: you don't need to work in your fork (on your account), you can directly work in this repo by using a branch for each feature you are working on and still start a PR to merge to master if you wish.

[goto40]

OK. I merge later today.

[igordejanovic]

@danixeee I agree. Seems that registration of language templates should be straightforward. Challenges for the editor noted by @goto40 still remain.

@goto40 For completion we need a list of all possible names/strings at the given position. We were using all sorts of tricks for this to happen. As we most often have uncomplete/unparsable model at that point I guess that the underlying Arpeggio parser should be the first level on which we shall implement a support for completion. If name is needed at the position the first thing we should find out is what rules/metaclass names are expected. Scoping rules come afterwards but require valid model to operate. This area still need some work/design.

[goto40]

We could use the scope provider api to alternatively yield names instead of one match (if we need support for an editor to provide suggestions to the user).

This would also work for the non textX model.

@danixeee: thank you for the example. I will adapt the project files.

[danixeee]

@goto40 NP, maybe you should wait until I finish with task textX/textX-LS#12. I will notify you when it is done and we can create an issue in this repository to add support for language server.

[goto40]

@danixeee I have just seen your message. Ok, I wait, no problem (to be continued in #3).