Syntax checking/SRS: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (13 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Projects]] | |||
[[Category:Editor]] | |||
[[Syntax_checking|back to Syntax checking page]] | |||
= Goal = | = Goal = | ||
Provide adequate, but non intrusive feedback to user about syntax errors. | Provide adequate, but non intrusive feedback to user about syntax errors. | ||
= Parser = | = Parser = | ||
# Should only parse when neccessary, using | # Should only parse when neccessary: | ||
## When editing a new or correct expression: | |||
# Provide errors in adequate datastructure to visualisation components (linenumber | ### After typing a point, comma, colon, semi-colon, space, tab or line-break | ||
# | ### After leaving the edited expression (using cursor or mouse) | ||
## When editing a incorrect expression: | |||
### After each added character | |||
# Provide errors in adequate datastructure to visualisation components (replaced by is_correct attribute on token) | |||
##linenumber | |||
##type of error | |||
##further information | |||
# 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 = | |||
# The parser invalidates a TOKEN, by settings its attribute is_correct to false | |||
# The parser can also set TOKEN's error_description attribute to the specific error (or error_type if we don't get description) | |||
# An additional data-structure has to be maintained, to pass error summary information to visualization | |||
= Visualization = | = Visualization = | ||
# | # Highlighting happens only in code editing view | ||
# Visualization component should maintain information on line states (underlined y/n) | |||
# Underline syntax errors using a (preferably wavy) red line | # Underline syntax errors using a (preferably wavy) red line | ||
# On mouse over, show information on error | # On mouse over, show information on error | ||
# Information window could be | # Information window could be clickable to provide further error information | ||
# Errors should be accessible over summarization | |||
= Suggestions = | |||
# To be implemented after parser and visualization components are feature complete | |||
# Suggestions based on information from parse tree | |||
# Analyzation based on soundex or other algorithm | |||
Latest revision as of 16:12, 15 June 2006
Goal
Provide adequate, but non intrusive feedback to user about syntax errors.
Parser
- Should only parse when neccessary:
- When editing a new or correct expression:
- After typing a point, comma, colon, semi-colon, space, tab or line-break
- After leaving the edited expression (using cursor or mouse)
- When editing a incorrect expression:
- After each added character
- When editing a new or correct expression:
- Provide errors in adequate datastructure to visualisation components (replaced by is_correct attribute on token)
- linenumber
- type of error
- further information
- 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
- The parser invalidates a TOKEN, by settings its attribute is_correct to false
- The parser can also set TOKEN's error_description attribute to the specific error (or error_type if we don't get description)
- An additional data-structure has to be maintained, to pass error summary information to visualization
Visualization
- Highlighting happens only in code editing view
- Visualization component should maintain information on line states (underlined y/n)
- Underline syntax errors using a (preferably wavy) red line
- On mouse over, show information on error
- Information window could be clickable to provide further error information
- Errors should be accessible over summarization
Suggestions
- To be implemented after parser and visualization components are feature complete
- Suggestions based on information from parse tree
- Analyzation based on soundex or other algorithm