Of course it does. Back in the day one couldn't take a megabyte file and say, "I'll just load it all into memory." When I worked in Visual Studio, it annoyed me to no end that VS had trouble loading large text files when ancient FoxPro (another MSFT dev product whose origins are from the 80s) would load them just fine. FoxPro didn't try to cram the whole thing in memory, just the parts it needed. I'm guessing vim and Emacs work in a similar manner. Don't use VS anymore, so I don't know if they ever fixed that or not. Particularly annoying is that it ever needed to be fixed, rather than being designed correctly (for which there was plenty of prior art) from the start.
Yes, but with the caveat that it's line based (1 dimensional) not 2 dimensional so a VERY long line can still choke vim and Emacs.
--- long time primary Emacs, secondary vim user
Have an upvote because (to quote Johnny Carson) I did not know that.
Re: FoxPro vs. VS, it's probably quite unfair to suggest that it's in part because FoxPro didn't start its life at Microsoft, but I admit it was the first thing that came to mind...
I say this as a long-time vim/emacs user... (yes, I've learned and use both although I primarily use vim).
So while I'll readily agree that I doubt they work as much at optimisation, they're also being asked to do significantly more.
I'm just trying to point out that attempting to compare applications from a certain period in computer history to modern applications is doomed to fail.
While I certainly believe optimisation work would help some modern editors, it would be silly to attempt to blame that all on optimisation work instead of recognising that the world is different now.
It's probably not simply the use of web technologies, but I'm quite sure it makes a difference. There's a lot of buzz about how slow Github's Atom is compared to Sublime Text, for instance. And BBEdit -- an old Mac text editor which often gets ignored these days as an unfashionable relic -- just loaded up a 24M, 181,000-line MySQL dump and is having no perceptible speed issues either scrolling the file or letting me insert new text on its first screen, even with syntax coloring enabled. The same was also true of Vim and Emacs (despite Emacs kvetching about the file's size when it loaded it).
It's my suspicion that the age of these warhorses may help them here rather than hurt them: serious editors twenty years ago required serious optimization work. While I do most of my programming in Sublime Text, there are certain times BBEdit is just the fastest tool for the job. If I was starting a new text editor, which I wouldn't, I'd be much more concerned about editing speed than it appears the developers of the current batch are.