Disable Langium Warnings

[snarkipus]

This should be an easy one ... the DSL I'm documenting the grammar for has some keywords that have white space (which is annoying). For example ... I have a grammar definition that looks like the following:

SDBBlock:
    ...
    'START TIME:' start=REAL uom=TimeUOM
    'STOP TIME:' stop=REAL uom=TimeUOM
    ...
'END SCENARIO' status=SDBStatus
;

Understandably, I get a ton of warnings of the type: Keywords should not contain whitespace characters.langium

Is there any easy way to turn this off?

It's also possible that I'm doing this all wrong and have missed something completely obvious to real language designers. :)

Thanks in advance.

[msujew]

Hey, so basically the warning is a nice reminder that keywords (even though the spec might say so) should never be whitespace sentitive in regards to lexing. The reasoning for that might not be completely obvious though:

When creating a keyword such as 'END SCENARIO', every user error such as END___SCENARIO (think each _ as being a whitespace) will be seen as a lexing error. I.e. both END and SCENARIO will likely be parsed as ID terminal tokens instead of keywords. This in turn will lead to a very difficult to understand parser error, as the parser only sees ID ID instead of the expected END SCENARIO.

On the other hand, there's a more user friendly way to deal with this issue. Obviously, it includes separating 'END' and 'SCENARIO' into distinct keywords as a first step. Then, if a user actually inputs something like END___SCENARIO, a custom validation should check that only a single whitespace appears between those keywords, emitting an understandable error message. The validation itself can be fairly simple:

checkWhitespace(block: SDBBlock, acceptor) {
  const endNode = findKeywordNode(block, 'END');
  const scenarioNode = findKeywordNode(block, 'SCENARIO');
  const document = getDocument(block);
  if (endNode && scenarioNode) {
    const spaceStart = endNode.range.end;
    const spaceEnd = scenarioNode.range.start;
    const range = Range.create(spaceStart, spaceEnd);
    const text = document.textDocument.getText(range);
    if (text !== ' ') {
      acceptor('error', "Expected a single space character between 'END' and 'SCENARIO'", { node: block, range });
    }
  }
}

Anyway, there's no way to turn validations off, we're currently investigating a strict mode for Langium (see #385), but there's nothing implemented yet.

[msujew]

so if I'm interpreting the validator code correctly (thank you for that btw)

You're welcome :) The validation for that is a bit non-obvious, since it doesn't use the AST (abstract syntax tree), but the CST (concrete syntax tree, which is heavily tied to the original input text, including position, etc), which is unusual for validations.

i.e. it doesn't care about the amount of white space ... only that the keywords are separate and in the proper order

Even better, then you don't even have to necessarily implement the validation. By the way, I would also recommend to split off symbols (i.e. : or similar) from keywords for the same reason as outlined above.

[snarkipus]

Interesting ... would 'of symbol' splitting include hyphenated keywords such as:

DataOption:
    option=('SAVE-DATA'|'DO-NOT-SAVE-DATA')
;

If so, langium seems to complain when I try to break it up.

[msujew]

Well, not necessarily, since it overcomplicates the assignment stuff. You can't assign a whole sentence so to speak to a single property. Something like this could work:

DataOption: ('SAVE' '-' saveData?='DATA' | 'DO' '-' 'NOT' '-' 'SAVE' '-' 'DATA');

That would set saveData to true if SAVE-DATA was written, and false otherwise. However, I believe using hyphens within a keyword is fine in that case.

[snarkipus]

That makes sense - thanks again @msujew! I think I'm making pretty solid progress ... my DSL LSP extension is slowly beginning to behave the way I think it should.

This is certainly much more straightforward than the Xtext approach using Xtend and the like (for me at least).

Question: would it be alright if I created an open-ended QA Discussion for general questions (that are non-lazy) as I work through this exercise? Maybe capturing the process of creating a LSP integration for an existing DSL would be helpful to the next neophyte who stumbles across this amazing tooling framework.

Ideally, I'd write a blog post ... but I'm notorious for getting distracted by shiny things and never get around to writing.

[msujew]

This is certainly much more straightforward than the Xtext approach using Xtend and the like

One of our initial claims was to reuse the good things about Xtext, but make it easy and quick to use. I'm glad too hear it holds up to expectations. :)

Question: would it be alright if I created an open-ended QA Discussion for general questions

Sure, we already had something similar from another user when we first released Langium. See #153. Feel free to post any progress/questions in there and ping me preferably. I'm happy to answer any questions.

but I'm notorious for getting distracted by shiny things and never get around to writing.

That sounds too familiar, probably one of the reasons our documentation is still so anemic.