Design of a Vim-like text editor

Post by rtpg » Sun, Jan 04, 2015, 2:14 AM UTC

chriswarbo wrote: post #89

rtpg wrote: post #70

Earlier quoted context omitted.

>For one thing, it means you cannot work with files larger than maybe 3 GB, or even 3 1 GB files, in a 32 bit process. Serious question : is it bad to assume a 64-bit capable running environment for developer's computers nowadays? I feel like it's better to run with something simple (and way less error prone) if the cost is some 32-bit issues like stated. Granted, vim is a special case, since we're running this throu…

> Serious question : is it bad to assume a 64-bit capable running environment for developer's computers nowadays? There's at least one counter-example, since all my machines are 32bit. Is there anything in particular about software developers which makes you think they're more likely to grind on the hardware upgrade treadmill? I would have thought the opposite. The software I use (linux + xmonad + bash + text editor)…

It's been 11 years since the widespread introduction of 64-bit processors in consumer hardware. I think it's a pretty safe assumption to make that a vast majority of people are using 64-bit-capable machines.

There are advantages to the "hardware upgrade" treadmill if you're on a laptop (not many laptops got 9 hours of battery life in 2003), and if you open an IDE from time to time, or do heavy consumer-facing web development, having a computer from the last decade is useful. Also easier to run a high-res multi-monitor setup if you have some good speed behind that.

It's possible to be good and capable on the machines you're citing, but the overwhelming majority of software developers (even the ones using vim/emacs) are not of the linux + xmonad type.

Post by marvy » Tue, Jan 06, 2015, 5:20 AM UTC

ridiculous_fish wrote: post #74

marvy wrote: post #72

Earlier quoted context omitted.

Um, how on earth do you deal with the 10GB delete? You can't store it in RAM, since there may not be enough, especially if you want 32 bit support. Store it on disk? You can't store it in the original file, since you have no flexibility over its contents after a save: a hex editor must write the bytes asked for, unlike a word processor which controls the file format. Ok, maybe we store it in some other file, call it…

The short answer is that it preserves the undo stack, if it can do so without using more than 16 MB of additional memory. If it exceeds that threshold it drops the stack. (Hey, I didn't claim to have solved it well!) The longer answer: when a file is going to be saved, HF identifies the ranges of the file that will be modified, and then identifies every other "byte array" (what vis calls a "piece chain") that referen…

You may not have solved it perfectly, but better than a version of Excel I once used. Every time you save, it drops the undo stack. No matter what. I think the latest versions have fixed this by now.

Re: Design of a Vim-like text editor

Re: Design of a Vim-like text editor