Hacker News Reader

Comment by teraflop | Hacker News Reader

> 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).

View on HN

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.

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.

Yeah Notepad++ asks you too. I don't know of any editors that silently discard changes by default.

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.

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.

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.

> 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.

That's great, which editor is that?

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/ultra...

EmEditor, it’s windows only: https://www.emeditor.com/

Isn't that what having offsets and mmaps are for? With that information, jumping lines becomes constant time.

Reply on news.ycombinator.com