Using external lists for auto-completion Follow

Do these external lists change often? Not that it really matters, I guess. You will always have to parse this other file one way or the other and transform it into a MPS model, so why not use the utilities that exist for such a use case mentioned in the other post? What functionality other than loading the file, parsing its input into a MPS model do you have in mind?

Thank you for the reply. The referred use case involves creating, building and deploying a plugin after parsing. It would be much easier for me to write a simple class with static methods, where I read the file, collect the information and pass it to something which can use this list to add the new auto completions.

I guess this latter point is hard to do, that's why it is not implemented.

Is it possible to generate concepts for the editor by extending an existing one? It would solve most of my problems.

Well, you could just give it a try to have a static class as a "node provider" and see if it works. You can use the node API to create the nodes you need, but you would also need to define the concepts in a language that you want to instantiate when reading the file. You need to decide at what point in time you would like to load the file, and then you would see pretty fast, that creating a project plugin is actually not that big of a deal...

Unfortunately, I don't understand what you mean by "generate concepts for the editor by extending an existing one"? 

"Unfortunately, I don't understand what you mean by "generate concepts for the editor by extending an existing one"? "

Let's say I have a concept called 'Parent' implementing INamedConcept. If I have defined this, then it is possible to have a concept, which requires 0..n 'Parent' as children. My assumption is the following: If I generate new concepts extending 'Parent' and their name property is defined, then the editor might realize that these new concepts fits in place of 0..n children (mentioned above) as they are sub-class of 'Parent'. If this is true, autocompletion should provide the generated (ready-to-use) concepts.

I will give it a try what you recommended regarding "node provider". If it fails to work custom persistences are still there as Plan B.

Thank you for your thoughts.

I think you need to make an important distinction between "concept" and "node".

In the scenario you describe, the concept 'Parent' is defined at development time. Building the language in MPS creates the underlying code that is necessary to instantiate this concept (a node<Parent>, users can instantiate these in the editor, for example by using the substitution menu.

If you deploy your language and users use it, you cannot easily "generate" new sub-concepts of Parent programmatically and hot-swap them into your running application/sandbox. I mean, I guess it is technically possible, but I feel like there is some confusion going on about concepts and nodes, when they are defined and how they relate. Unless I misunderstand you, you want to dynamically change the language definition while users use the language... that sounds way more complex than just creating a plugin.

I'm also unsure what you mean by "and their name property is defined". This might mean you are actually talking about nodes, not concepts. But nodes cannot "extend" concepts, a node is an instance of a concept (technically, a concept is also a node, but it's on a different meta-level).