Difference between revisions of "Syntax checking/SRS"
 
(14 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 timer function or after certain input (like spaces, enter)
+
# Should only parse when neccessary:
−
  (to be further specified )
+
## When editing a new or correct expression:
−
# Provide errors in adequate datastructure to visualisation components (linenumber, type of error, further information)
+
### After typing a point, comma, colon, semi-colon, space, tab or line-break
−
# On error, parser should call event handler provided by visualization components
+
### 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 =
−
# Provides event handler and register it to parser error-event
+
# Highlighting happens only in code editing view
−
# Underline syntax errors using a (preferably wavy) red line
+
# Visualization component should maintain information on line states (underlined y/n)
−
# On mouse over, show information on error
+
# Underline syntax errors using a (preferably wavy) red line
−
# Information window could be clickabel to provide further error information
+
# 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

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
Retrieved from "https://dev.eiffel.com/index.php?title=Syntax_checking/SRS&oldid=3494"