4 ms·

> A truly efficient implementation would never need to load the entire original file in RAM. It would just need to remember the binary offset of each line Exce

> A truly efficient implementation would never need to load the entire original file in RAM. It would just need to remember the binary offset of each line Except that this would most likely result in unpredictable corruption if another process modified the file while you had it open, which is contrary to the way basically every text editor works. It would be nice if there was a way to mmap a file in such a way that the OS would give you a snapshot view, but AFAIK that doesn't exist, at least on Linux in a filesystem-agnostic way (not sure about other operating systems).

dataflow 5y ago
I think every platform supports FS notifications at least right? The app could listen for changes to the file and reload/discard when it goes out of sync. In fact Notepad++ already does this. On Windows in particular you also have a ton of other facilities that could help with this (opportunistic locks, transactions, etc.) but notification is usually good enough.
- chongli 5y ago
  My main editor is vim. It notifies the user when a file you have open in a buffer gets modified on disk by another process. It explicitly gives you the option to load the file from disk at this time. I would not use a text editor which silently reloads a file because this could result in a loss of work.
  - dataflow 5y ago
    Yeah Notepad++ asks you too. I don't know of any editors that silently discard changes by default.
  - workerdrone451 5y ago
    While many editors will come and go, vi in some form will always remain. Once you "get" it, using anything else starts to become alien.
phendrenad2 5y ago
This would also be too slow. The user may want to jump from line 1 to line 999999. You can't do a file load fast enough.
- Semaphor 5y ago
  > This would also be too slow. The user may want to jump from line 1 to line 999999. You can't do a file load fast enough. My text editor supports files up to 256 GB in size, unless you have that much memory, you’ll have to wait a little bit to go from the first to the last line.
  - andai 5y ago
    That's great, which editor is that?
    - erwincoumans 5y ago
      I use UltraEdit, it opens files way beyond hundreds of GB without issues, both text and binary (in hex edit mode). Love that editor for over 10 years (perpetual license) on Windows, Mac and Linux. See the video loading a 35GB text file: https://www.ultraedit.com/support/tutorials-power-tips/ultraedit/large-file-handling.html https://www.ultraedit.com/support/tutorials-power-tips/ultra...
    - Semaphor 5y ago
      EmEditor, it’s windows only: https://www.emeditor.com/ https://www.emeditor.com/
- erwincoumans 5y ago
  Isn't that what having offsets and mmaps are for? With that information, jumping lines becomes constant time.
bccdee 5y ago
Not necessarily. It's possible to listen for file updates and respond accordingly on the fly by re-reading the file and updating all your offsets and mmaps. It doesn't even have to be efficient; it's not a common case.

dataflow 5y ago

I think every platform supports FS notifications at least right? The app could listen for changes to the file and reload/discard when it goes out of sync. In fact Notepad++ already does this. On Windows in particular you also have a ton of other facilities that could help with this (opportunistic locks, transactions, etc.) but notification is usually good enough.

chongli 5y ago
My main editor is vim. It notifies the user when a file you have open in a buffer gets modified on disk by another process. It explicitly gives you the option to load the file from disk at this time. I would not use a text editor which silently reloads a file because this could result in a loss of work.
- dataflow 5y ago
  Yeah Notepad++ asks you too. I don't know of any editors that silently discard changes by default.
- workerdrone451 5y ago
  While many editors will come and go, vi in some form will always remain. Once you "get" it, using anything else starts to become alien.

phendrenad2 5y ago

This would also be too slow. The user may want to jump from line 1 to line 999999. You can't do a file load fast enough.

Semaphor 5y ago
> This would also be too slow. The user may want to jump from line 1 to line 999999. You can't do a file load fast enough. My text editor supports files up to 256 GB in size, unless you have that much memory, you’ll have to wait a little bit to go from the first to the last line.
- andai 5y ago
  That's great, which editor is that?
  - erwincoumans 5y ago
    I use UltraEdit, it opens files way beyond hundreds of GB without issues, both text and binary (in hex edit mode). Love that editor for over 10 years (perpetual license) on Windows, Mac and Linux. See the video loading a 35GB text file: https://www.ultraedit.com/support/tutorials-power-tips/ultraedit/large-file-handling.html https://www.ultraedit.com/support/tutorials-power-tips/ultra...
  - Semaphor 5y ago
    EmEditor, it’s windows only: https://www.emeditor.com/ https://www.emeditor.com/
erwincoumans 5y ago
Isn't that what having offsets and mmaps are for? With that information, jumping lines becomes constant time.

bccdee 5y ago

Not necessarily. It's possible to listen for file updates and respond accordingly on the fly by re-reading the file and updating all your offsets and mmaps. It doesn't even have to be efficient; it's not a common case.