-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support of very big files #465
base: master
Are you sure you want to change the base?
Conversation
Can you update this commit to not include all of the whitespace changes? It will make the PR easier to review and avoid unnecessary changes to git history. |
Sure, I miss disable the automatic format before pushing. REVIEW NOTE: Big changes are in TextEditorPane in order to manage two different document types. |
635a87e
to
5cc7802
Compare
Hi, @bobbylight do you have any feedback? I know that changes have some impact on the editor's architecture. With these modification, we should add support for two types of documents. Thanks |
Hi @basix86 ! I'm tying to wrap up a minor release with mostly keyboard issues before going on holiday for EOY. I'll dig into this and other meatier stuff after that release. |
@bobbylight have you planned the release date? |
This pull request aims to add the possibility of reading a huge file (e.g. log files)
Usually when a file is opened all contents are copied into memory. This approach can be memory-consuming with very big files.
Example of warning of RText:
To solve the problem I have used a paging approach.
I suppose that, in a text editor, there are many sequential reads, always in the same zone of the file.
I copy in memory only a part of the file (e.g. 1 MB) and relative offset.
When we need to access another zone of the file (e.g user scrolls down in the file, we change the offset, and we reload the new part of the file).
The offset is not easier to manage. For that region, I choose to open the file in read-only mode.
The same approach used in IntelliJ: