Skip to content
Igor Malyushkin edited this page Jun 11, 2024 · 8 revisions

With 0.1.8 Thymus introduces the editor capabilities. Now there are two modes for a working context view and edit. The former is familiar to an experienced Thymus user, this mode is also by default. The latter is something new.

In this memo the text term is interchangeable with the configuration file.

Switching between modes

A working screen (or context) is in the view mode by default. One can notice a greenish label in the bottom right corner denotes the current mode. To enter the edit mode, a user sends the edit command. We recommend visiting a specific path (a part of the configuration) before doing so. This is because displaying a large portion of text may be slow on some systems.

The smaller a configuration block the faster the loading time.

After a user enters the edit mode, Thymus starts drawing the corresponding part of the configuration. If it is big enough, Thymus displays a special overlay widget. At the same time, the main screen is running the loading indicator instead of the text. This is to make the application more responsive during the loading.

image

The overlay widget displays a count of loaded lines into the Editor widget and a count of total lines. Click on the widget to stop loading and back to the view mode.

Another option to leave the edit mode is the exit command.

Exiting from the editor mode will silently discard any changes!

Tuning the loading

One can slightly increase the drawing speed. First, it is important to know any speed-ups can lead to the hanging of the application. There are always some tradeoffs.

The editor_frequency_factor is the gap between two consecutive portions sent to the Editor widget. In other words, the data of a specific path must be loaded to the Editor, so they are split into chunks. These chunks are sent to the Editor with the time gaps among them. The smaller gap, the faster the completion time. At the same time, this gap is vital to the overall performance, it gives Thymus some time to react to other events (e.g., to refresh its UI).

There are four possible options for the editor_frequency_factor. By default, it is 4 which means 0.4 sec gap.

The editor_scale_factor is a dynamic count of lines sent to the Editor widget. This is the size of the chunk. This size depends on two factors. The first is a vertical window size. The second is the value of this setting itself. They produce the total number of lines in the chunk. For example, if the vertical size is 80 lines and the scale factor is 2, the chunk size is 160. Thus, for each update, the Editor will be fed 160 lines.

One can specify a value in the 1 to 4 range. By default, it is 2.

Committing

An edited path (its content) must be committed to preserve the changes. There is the commit command for that goal. Thymus tries to validate the changes before making them permanent. It includes several steps:

  • Committing empty data is prohibited. There are some internal reasons for this. If you want to purge a path content, do it from the previous hierarchy.
  • Redundant statements or sections are also a barrier.
  • Things that broke the syntax tree are considered invalid:
    • Forgotten brackets where they apply.
    • Indentation mistakes. Again, for some internal reasons, the indentation of any new data must follow the current minimum.
  • Content must end with the new empty line, its indentation must be absent (the only exception). Check the presence of more than one empty line, it is considered a mistake!

After a successful commit, Thymus creates a new context and increases the current context number by one. That is how one can follow the progress of changes. Modified data is not saved into a source file by default! Even if after a commit. To save the data, use the save command (do not confuse it with the sub-command) from the view mode.

One can set the global setting save_on_commit which saves data after every successful commit. Pay attention, the setting starts working for the next opened file!

History

After the first commit, Thymus creates a special file with the ".history" extension. Its name is the same as the name of the opened one. The Open dialog does not show history files!

History files are binary compressed JSON files (it requires the msgpack library). They contain only changes of the original file from one commit to another. Thymus looks for the optimization of memory usage in terms of RAM and disk space.

Next time, when a file that has its history log is opened, Thymus loads this history and produces contexts for all commits. The last commit becomes a current working one.

At the moment, there is no option to load a file without its history when the file has it. Move its history file aside for that manually.

Rolling back

A user can discard any changes in a chain. An original text (without a history) always has an index of zero. Thymus considers an opened configuration as a context. Before 0.1.8, there was only one context per the Working screen. Sometimes we call the latter the Working context. Now, the Working screen can hold more than one context (a variant of an opened configuration). Every variant has its consecutive index comprising a chain.

Any user's commands apply to the latest variant in the chain. In other words, the show command will show the content of the recently modified version of the configuration. To better understand the changes that were made a user may compare the current context with any previous one. For that goal, the diff sub-command supports rollback modification. This modification requires an index of the previous context. For example, the show | diff rollback 1 command displays the diff-output of all the changes that were made from the context of the index one toward the latest one.

One can redefine the diff sub-command by any other option. The rollback keyword can not be modified!

Finally, in the edit mode a user can discard changes. Discards are cumulative. This means that rolling back to a point in the chain discards all the changes after the point. In other words, if the current context index is 5, rolling back to the index of 2 discards: 5, 4, and 3 contexts. There is the rollback command for the edit mode, it requires a single argument of a context index.

After a rollback, Thymus exits from the edit mode to the view mode. It automatically sets the root path as a working one for the current context.

To ease a rollback operation, it is better to visit an arbitrary path that has little content before entering the edit mode. The path itself is unimportant in terms of the rollback, Thymus ignores it.

Clone this wiki locally