# xText keywords aus resource file



## Atze (16. Nov 2011)

weiß jemand ob / wie es möglich ist per textdatei o.ä. einen haufen keywords in xtext bekannt zu machen.

muss auch nicht dynamisch sein (wäre schön wenns auch geht), es reicht wenn ich beim generieren über das mwe2 irgendwie in der grammar ein strukturiertes file angeben kann, wo er sich die datentypen, keywords etc rausziehen kann.

was ich mich zusätzlich noch frage ist, wenn ich (später im editor) eine variable anlege erkennt er diese und zeigt sie auch in der outline. er erkennt es also als ID und verhindert auch doppelungen etc. warum packt xtext diese variable nicht auch in die autovervollständigung? kann man dies aktivieren? ist das dynamisch überhaupt möglich?


----------



## Wildcard (16. Nov 2011)

> muss auch nicht dynamisch sein (wäre schön wenns auch geht), es reicht wenn ich beim generieren über das mwe2 irgendwie in der grammar ein strukturiertes file angeben kann, wo er sich die datentypen, keywords etc rausziehen kann.


AFAIK nicht, das erscheint mir auch nicht sehr sinnvoll. Was bringt ein Keyword wenn es in keiner Regel verwendet wird?


> er erkennt es also als ID und verhindert auch doppelungen etc. warum packt xtext diese variable nicht auch in die autovervollständigung? kann man dies aktivieren? ist das dynamisch überhaupt möglich?


Xtext tut das bereits. Allerdings ist die Completion Kontextsensitiv, die Variable wird also nur als Referenz vorgeschlagen wo das auch sinnig ist. Anders gesagt, du brauchst irgendeine Regel die das entsprechende Objekt referenziert. In der Grammatik sieht das dann etwas so aus:

```
Variable :
  name=ID;
 
VariableReference :
  variable=[Variable];
```
Im Ecore wird daraus eine Klasse Variable und eine VariableReference.
VariableReference hat eine EReference 'variable' vom Typ Variable.
Wenn du nun an eine Regel kommst du eine VariableReference erwartet, wird dir Xtext alle in diesem Scope sichtbaren Variablen in der Autocompletion anbieten.


----------



## Atze (17. Nov 2011)

ok, danke für die info für punkt2, das hilft mir auf jeden fall weiter! 

aber bei den keywords wäre schon geil, wenn es sowas gäbe. klar sollen die keywords aber alle in eine regel, aber allein das händische einpflegen nervt ab einer gewissen menge schon.

angenommen ich möchte einen satz aus 200 basiskeywords und funktionen anbieten. muss ich die manuell alle mit dem selben muster in eine regel pflegen? müsste ich ja dann wohl machen, aber geht das nicht einfacher?


----------



## Atze (17. Nov 2011)

@wildcard: hast du ne idee we man freetext / plaintext erlauben kann?

ich würde gern die möglichkeit bieten in einem bereich einerseits die autocompletion anzubieten (funktioniert jetzt, danke nochmal  ) , andererseits aber auch die möglichkeit geben, text zu tippern den der parser nicht kennt.

so wie ich das bis jetzt verstanden habe schließt sich das gegenseitig aus, oder denk ich da falsch?

mein problem ist, dass es einen haufen standard funktionen gibt die ich ja in den regeln hart verdrahten kann (dafür wollte ich gern das einlesen über einen resourcedatei nutzen, aber das hat sich wohl erledigt :/ ), aber auch neue funktionen anderer klassen (für die [noch] keine validierungsmöglichkeit besteht) zulassen möchte.

irgendwie steh ich konzeptionell da grad auf dem schlauch. :/


----------



## Wildcard (17. Nov 2011)

Wie genau stellst du dir das vor? Freitext muss natürlich in irgendeiner Weise in den Regeln hinterlegt werden, wie zum Beispiel bei Kommentaren, oder in String Literalen. Über invisible Rules lässt sich das ganze aus dem Domain Modell heraushalten (passiert per Default auch schon bei Kommentaren).
Aber für mich hört sich das eher so an als sollte in der Datei beliebiges an beliebiger Stelle stehen können?
Dir ist klar das es hier um strukturierte Sprachen die maschinenlesbar sind?


----------



## Atze (17. Nov 2011)

Wildcard hat gesagt.:


> Wie genau stellst du dir das vor? Freitext muss natürlich in irgendeiner Weise in den Regeln hinterlegt werden, wie zum Beispiel bei Kommentaren, oder in String Literalen. Über invisible Rules lässt sich das ganze aus dem Domain Modell heraushalten (passiert per Default auch schon bei Kommentaren).
> Aber für mich hört sich das eher so an als sollte in der Datei beliebiges an beliebiger Stelle stehen können?
> Dir ist klar das es hier um strukturierte Sprachen die maschinenlesbar sind?



ja, das ist soweit klar  deswegen frag mich mich ja (falls ich das nicht anders hinbekomme), ob es möglichkeiten gibt die regeln so weit zu schwächen, dass ich bestimmte bereiche definieren kann, in denen dem DOM, AST (oder wie auch immer das ding heißt) zur laufzeit nicht alle textteile bekannt sein müssen, aber dürfen (für die autovervollständigung). mir ist klar, dass in diesen bereichen dann keine validitätsprüfung stattfinden kann, woher soll der parser auch wissen, ob der das jetzt kennen muss und rot unterringeln würde, oder mir das durchgehen lässt.

ich wollte nur generell wissen, ob es halt eine möglichkeit gibt ihm zu sagen A:"an dieser stelle darf alles stehen, stings als literale in klammern, einfach irgendwas, operatoren etc". das wäre zumindest teilweise ne hilfe, aber ich denke ich muss anders vorgehen und versuchen alles bekannt zu machen.

und falls A: ginge (was ich mir garnicht so abwegig vorstelle, da es dann wie kommentare behandelt werden soll, nur ohne quotes), wäre ein super feature noch B:"und auch wenn da alles stehen darf, biete mir trotzdem autocompletion, wenn du was wiedererkennst!" aber das wäre nice to have ... :/


----------



## Wildcard (17. Nov 2011)

> und falls A: ginge (was ich mir garnicht so abwegig vorstelle, da es dann wie kommentare behandelt werden soll, nur ohne quotes), wäre ein super feature noch B:"und auch wenn da alles stehen darf, biete mir trotzdem autocompletion, wenn du was wiedererkennst!" aber das wäre nice to have ... :/


Sowohl A, als auch B ist möglich, da wirst du aber etwas tiefer einsteigen müssen.
Zu B, das Keyword heißt Rich String, schau mal hier unter "Lexer improvements (white space aware, rich strings)"
Xtext - New & Noteworthy

Zu A, alles machbar solange du daraus eine eindeutige Grammatik produzieren kannst. Wenn der Parser später aus einer Eingabe 2 verschiedene Produktionen bilden kann, ist es nicht eindeutig (und Antlr wird dir beim generieren einen Fehler werfen)


----------



## Atze (17. Nov 2011)

ich werd reinschaun, danke


----------

