Rodin Keyboard: Difference between revisions
From Event-B
Jump to navigationJump to search
imported>Nicolas mNo edit summary |
imported>Nicolas |
||
| Line 27: | Line 27: | ||
# Maintain a coherent caret position | # Maintain a coherent caret position | ||
# Keep spacing unchanged | # Keep spacing unchanged | ||
# Support statically contributed combinations | # Support statically contributed combinations (add) | ||
# Support dynamically contributed combinations (add and remove) | # Support dynamically contributed combinations (check validity, add and remove, will be useful for theories) | ||
#:+ maybe handle a scope ? could help when working with 2 projects that define the same combination input for different outputs | |||
# Avoid non-termination cases (combinations that produce input of combinations) | # Avoid non-termination cases (combinations that produce input of combinations) | ||
| Line 35: | Line 36: | ||
# In order to avoid non-termination, we will set a stronger requirement: the translation must be idempotent for any given input chain, caret position and set of combinations | # In order to avoid non-termination, we will set a stronger requirement: the translation must be idempotent for any given input chain, caret position and set of combinations | ||
# The translator must check that combination input tokens are either text or math symbols | # The translator must check that combination input tokens are either text or math symbols | ||
# The translator must check that combination output tokens are math symbols | |||
# The translator must not process a token that has the caret over it | # The translator must not process a token that has the caret over it | ||
# Once a symbol has been translated, it can never be translated back into its original text form (even virtually during a translation) | # Once a symbol has been translated, it can never be translated back into its original text form (even virtually during a translation) | ||
Revision as of 13:43, 12 May 2014
The Rodin Keyboard is an extensible keyboard for inputing mathematical formula (in Unicode). The Rodin keyboard provides the following facilities:
- A ModifyListener (RodinModifyListener) that can be attached to a SWT widget. When the content of the widget is modified, the keyboard reacts and translate the content accordingly. Currently, RODIN Keyboard supports Text and StyledText widget.
- An utility class Text2MathTranslator with a static method translate(String) for manually translating any string (or sub-part of a string) into mathematical formula.
- An Eclipse View called Rodin Keyboard View which provides an text input area which will translate the input text into mathematical formula. This View can be found under category RODIN.
The Rodin Keyboard however does not contain any pre-defined translation rules for any mathematical symbols. Instead, this task is left for the developers who want to declare different "keyboards" corresponding to the mathematical language that they want to use. Moreover, different combinations can be used to enter the same mathematical symbols.
Currently, there are two keyboards available:
- Standard keyboard for Event-B.
- LaTeX-style keyboard for Event-B.
Specification
Definitions
- Translator: function that transforms a (source chain, source caret position) into a (target chain, target caret position)
- Token: character sequence in a chain that is of one lexical kind, as long as possible
- Transformation Rule: specification of the modification of a token sequence into another token sequence
- Combination: specification of a transformation from a single input token into another single output token
- There are 3 kinds of lexical entities in a source chain:
- spacings (space, tabulation, end of line, ...)
- text symbols (identifier-like)
- math symbols (all other symbols)
Functional Needs
- Translate a whole chain all at once
- Translate on the fly, characters being typed in continuously
- Maintain a coherent caret position
- Keep spacing unchanged
- Support statically contributed combinations (add)
- Support dynamically contributed combinations (check validity, add and remove, will be useful for theories)
- + maybe handle a scope ? could help when working with 2 projects that define the same combination input for different outputs
- Avoid non-termination cases (combinations that produce input of combinations)
Requirements
- In order to avoid non-termination, we will set a stronger requirement: the translation must be idempotent for any given input chain, caret position and set of combinations
- The translator must check that combination input tokens are either text or math symbols
- The translator must check that combination output tokens are math symbols
- The translator must not process a token that has the caret over it
- Once a symbol has been translated, it can never be translated back into its original text form (even virtually during a translation)
