The Large File Editor is capable of opening huge document, 1000s GigaBytes, larger in fact there is no practical limit to the size of file it can open. When a document is opened in Liquid XML Studio that is to large load into memory, the Large File Editor is used instead.
The Large File Editor differs from standard editors in that it does not need to load the entire document into memory. In order to accomplish this the editor loads only the sections of the document that are visible on screen, and when edits are made, only the changes to the document are held in memory, meaning that working with ridiculously large documents can be done on a low spec PC while maintaining a responsive user interface.
In order to accomplish this internal the editor is quite different to conventional editors, much of this is implementation detail and nothing the end user needs to be aware of, but it does lead to a few quirks.
Clipboard operations within the same document are unlimited in size and take place at a very low (memory) cost, allowing GB cut and paste operations instantly. Limits are placed on the amount to text data that can be placed on the clipboard for use in other applications (you can't copy a 10 TB of text onto the clipboard, windows wont like it!).
The Large File Editor supports unlimited multi-step undo and redo. Again these actions are at a very low cost, making them fast and efficient.
Standard Find/Replace functionality is supported within the editor, but given the size of the documents may take a while, scanning though huge files takes time!
The standard text encodings are all supported including Unicode and UTF-8.
Because the description of the edited document is a combination of the current document on disk and the in memory change list, when the document is saved a copy is made, the original deleted and the copy renamed to be the original. As a result you need enough free space to create a copy of the file plus your changes, it also means that even a trivial change may be slow to save (at least as long as it takes to copy the file using Windows commands or Windows explorer).
As a result of saving the document the undo/redo buffer is lost (the undo actions were recorded against the changes to the original file, when the document is saved the original document has been changed and our undo list is no longer of any use).
The undo/redo buffer is not effected when SaveAs is used.
In a standard text editor the position in the document (and therefore the vertical scroll position) is worked out based on the line number the caret is on. However the only way to know the current line number is to count all the lines from the start, this would make the user interface too slow to use. So instead the vertical scroll position is calculated from the byte offset of the caret, this may not accurately reflect the position in the file (most notably in small files, or files with a long run of short lines followed by a run of long lines), but works well enough in practical examples.