-
-
Notifications
You must be signed in to change notification settings - Fork 9
Read & Writes
Tonic manage file writes and save files using various techniques and optimizations to provide a smooth user experience. Here are some of the ways it handles file writes:
-
Buffering: Tonic use in-memory buffers to store changes made to a file. When a user makes changes to a file, the changes are stored in the buffer instead of being immediately written to the disk. This helps minimize the number of disk I/O operations and improves performance.
-
Auto-save: Tonic implements an auto-save feature that automatically saves changes to the file at regular intervals or when specific triggers occur, such as losing focus on the editor window. This ensures that the user doesn't lose their work due to unexpected application crashes or system failures.
-
Atomic writes: When saving a file, Tonic often use atomic write operations to ensure that the file's contents are not left in an inconsistent state if the write operation fails midway. This typically involves writing the new content to a temporary file, then renaming the temporary file to replace the original file once the write operation has completed successfully.
-
File locking: To prevent multiple applications from writing to the same file simultaneously, Tonic may use file locking mechanisms to ensure that only one application can write to the file at a time. This helps maintain the integrity of the file and avoid potential data corruption.
-
Change detection: Tonic often monitor the files in the project for changes made outside the IDE. If a file is modified externally, it will prompt the user to reload the file, merge the changes, or ignore the changes.
-
Version control integration: Tonic integrates with version control systems (such as Git, Mercurial, or SVN) to manage file changes, allowing users to commit, revert, or view the history of changes made to the files in the project.
Tonic uses Isar database to buffer source file changes and write to the file as per following behaviour:
- On Save: This is the most straightforward and expected behavior. Users are accustomed to pressing a "Save" button (or shortcut) when they want their changes written to disk. This is a good default behaviour.
- Auto-save after delay: Tonic writes changes to the file after a certain period of inactivity in the text field (like 2 seconds without new changes).
- Auto-save on losing focus: Another strategy is to save changes whenever the text field loses focus (i.e., the user clicks somewhere else).
- Running Tests or Building the Project: Often, running tests or building the project involves executing the code that's currently saved to disk. If the latest changes in the editor haven't been saved, then the tests or build might not reflect the current state of the code. Saving before these operations can ensure that the operations run on the latest version of the code.
- Switching Branches or Pulling Latest Changes: In case of version control system like Git, operations like switching branches or pulling the latest changes can modify the contents of files on disk. If there are unsaved changes in the editor, these could be overwritten by these operations. Saving before performing these operations can prevent unsaved changes from being lost.
- Multi-view File: On split-view or duplicate view, save any changes before. This way, the changes to the current file won't be lost when the user switches to a different view of same file.
Tonic Core reads files using the file system APIs provided by the underlying operating system. When a user opens a file, the editor reads the file's contents and displays it in a new editor tab.
Here's a simplified overview of the process:
-
File open request: When a user opens a file, either by clicking on it in the file explorer or using the "Open File" menu command, Tonic receives a file open request with the file's path.
-
Reading the file: Tonic then uses Dart file system APIs (such as
fs.readAsString()
) to read the file's contents. These APIs interact with the underlying operating system to access the file and read its content. -
Handling large files: Tonic has special handling for large files to avoid performance issues. When a file is too large, it may open it in a "Large File Mode" that disables certain features like syntax highlighting and tokenization to improve performance.
-
Encoding detection: While reading the file, Tonic also detects the file's character encoding (such as UTF-8, UTF-16, etc.). This ensures that the file's content is displayed correctly in the editor. Encoding detection is done using heuristics and user-configurable settings.
-
Displaying the file: After the file's contents are read and its encoding is detected, the content is displayed in a new editor tab. The file's syntax highlighting, code folding, and other language-specific features are applied based on the detected language, as mentioned in the previous answer.
-
File system watching: Tonic also sets up file system watchers to monitor the opened file for any external changes. If the file is modified outside of Tonic, the editor will automatically update the displayed content or prompt the user to reload the file, depending on the user's settings.
Reading code from the buffers after an unexpected shut down, crash to recover and restore unsaved changes.