Latest revision as of 07:12, 15 June 2006

back to Syntax checking page

Goal

Provide adequate, but non intrusive feedback to user about syntax errors.

Parser

1. Should only parse when neccessary:
   1. When editing a new or correct expression:
      1. After typing a point, comma, colon, semi-colon, space, tab or line-break
      2. After leaving the edited expression (using cursor or mouse)
   2. When editing a incorrect expression:
      1. After each added character
2. Provide errors in adequate datastructure to visualisation components (replaced by is_correct attribute on token)
   1. linenumber
   2. type of error
   3. further information
3. Whenever the visualisation of an expression should change, the parser should call an event handler provided by visualization components

  Note:
  * A new expression is correct until it becomes incorrect.
  * The state of an expression can only be changed when the cursor leaves it.

Parser-to-Visualization-Interface

1. The parser invalidates a TOKEN, by settings its attribute is_correct to false
2. The parser can also set TOKEN's error_description attribute to the specific error (or error_type if we don't get description)
3. An additional data-structure has to be maintained, to pass error summary information to visualization

Visualization

1. Highlighting happens only in code editing view
2. Visualization component should maintain information on line states (underlined y/n)
3. Underline syntax errors using a (preferably wavy) red line
4. On mouse over, show information on error
5. Information window could be clickable to provide further error information
6. Errors should be accessible over summarization

Suggestions

1. To be implemented after parser and visualization components are feature complete
2. Suggestions based on information from parse tree
3. Analyzation based on soundex or other algorithm