history only applies to a set of text entry that was 'purged' from the input buffer. Those constitute a distinct logical group. the history functionality is a listener to events that are sent by the actors: - action handler -> fires event about purged text that will affect the history status (add new text, increase existing text display priority, remove older texts, etc) fires event about a key-chord that symbolizes history control and requests a response from the history handler.
history saves profile information, and loads them at user login. --> add user login event --> add user profile, and user profiles manager --> history trims all blank lines before and after a text input this allows for clear history entries, and prevents the history action to unadvertedly execute an impacting operation
'record' plugin is similar to history plugin, except it allows to store a series of distinct logical groups, and give it a name. It registers its SyntaxTree at the registration process and listens to both 'purge-event' events as well as the transitions it has in its syntax tree --> add concept of transition that is of type 'global' which means that it exists on all nodes --> add concept of isTransitionEnabled(), to allow for some transitions to be disabled (for example, one of 'start-record' or 'end-record' would be present depending on the context value _RECORDING_IN_PROGRESS... --> add a 'start-record' and 'end-record' and 'save-record' to profile giving it a name to the
