| Age | Commit message (Collapse) | Author |
|---|
|
Previously `kill` merely destroyed the terminal widget. This is contrary to the expected notion of `kill`, i.e. actually killing the process explicitly instead of relying on side effects.
The normal mode `d` verb now explicitly destroys the current item's content, be it a terminal widget or a history view.
|
|
|
|
|
|
|
|
|
|
|
|
`TerminalItem`'s `reset` member method wrongly performed a visual selection change which led to inconsistency when calling `kill` on a non-selected index.
Visual selection update is now performed on history view instantiation.
|
|
|
|
|
|
|
|
|
|
Otherwise one can not easily enter more complex shell commands such as pipe chains and so on.
The goal of _MetaTerm_ is not to implement a new shell language but to facilitate existing ones which is why this is best deferred to an existing application.
|
|
If a non-interactive applications terminates the next item is automatically selected in insert mode as to make the behaviour in this context more simmilar to normal shells.
Normal mode has to be entered explicitly for the highlighting to update on `HistoryViewer` instantiation.
|
|
Child processes of _MetaTerm_ may be terminated using other ways that the integrated kill command.
Automatic terminal widget destruction in such a event prevents the user from viewing the output of non-interactive applications.
This requires _MetaTerm_ to display the application's output after it was terminated.
This requirement is implemented via the new `HistoryViewer` widget that is instantiated after the terminal widget instance has been destroyed.
|
|
|
|
|
|
|
|
|
|
i.e. serialize objects to JSON.
|
|
|
|
|
|
Trailing whitespace was falsely recognized as a separate argument and as such led to resetting configuration values without obvious cause.
|
|
|
|
This enables the user to straight forwardly change all application settings via command mode.
During the implementation of this change I discovered that the way I was passing around `StateHandler` and `SettingsHandler` instances using properties was unnecessary. If all object instances are created in a common hierarchy they can access each other by their `id` property - i.e. `settings` and `mode` are available to the whole application without property trickery.
|
|
Otherwise they are not accessible to JS commands, i.e. they can not be changed in command mode.
|
|
`list` holds the components of the central list UI element.
`command` holds the UI and implementation parts of the command mode.
`widget` holds more or less general purpose elements that may also be of use in other circumstances.
|
