8 ms·
Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vi
by dfabulich 6y ago
Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim.
I think it comes down to performance, especially startup time. Emacs developers have never cared much about it, and I think that's connected to its reputation for "bloat."
The death knell rang when Linux distros stopped distributing Emacs by default; Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or the Windows Subsystem for Linux.
If I were working on Emacs, my #1 goal would be to beat Vim on startup time--to get the first page of text to show up faster than Vim--and my #2 goal would be to convince the major distros to include Emacs by default.
Sadly, I don't think any of this will happen. Stallman is too far out of touch, not just with newbies, but even with active users of Emacs. As the article points out, he's never even used Org mode! https://lwn.net/ml/emacs-devel/E1jR5ss-0001xM-L9@fencepost.gnu.org/ https://lwn.net/ml/emacs-devel/E1jR5ss-0001xM-L9@fencepost.g...
EDIT: I know you can do some non-default techniques to make Emacs start faster. But that won't get Emacs to be installed by default on popular distros. Installing more plugins won't make Emacs the quickest and easiest way to edit a file.
- throwaway8941 6y agoStartup performance problems can be sidestepped with emacs daemon mode, at least in some cases. https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Em... https://www.emacswiki.org/emacs/EmacsAsDaemon https://www.emacswiki.org/emacs/EmacsAsDaemon
- daffy 6y agoemacs -Q opens instantaneously
- dfabulich 6y agoNot as fast as Vim. I just tried it on a 500KB SQL script; Vim opened instantly. emacs -Q took a while to flash something on the screen.
- celeritascelery 6y agoStartup time can actually be really good if you configure it right. Stock Emacs is about 150ms for me. There is also a portable dumper that will save your Emacs boot Image to memory for faster loading. Also check this out. https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_emacs_so_damn_fast/ https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_e...
- dfabulich 6y agoSure, or you could use "emacs -Q," but all of those performance improvements are off by default, and it seems like they always will be. As long as that's true Vim will always be the quicker and easier way to modify a file.
- cat199 6y agonah, just wait for the next version of systemd, I hear everything will be fixed with systemd-weyland-kitchensink-emacsd edit: am emacs (and nvi) user. just chiming in on .1ms vs 1ms startup time arguments as a basis for anything important
- matthewbauer 6y ago-Q shouldn’t give you any better startup time than vanilla emacs.
- yaantc 6y agoSome distros have significant Emacs start-up configurations, which have an impact on start-up time. Using "-Q" skips this too. It's the case for Debian, so Ubuntu too I guess. I used to use "jed" as a close to Emacs, light text editor to use for a quick edit from the shell. Nowadays I aliased jed to "emacs -nw -Q" (-nw: text mode, -Q: skip all configs), which subjectively starts instantaneously. And even a bare Emacs skipping the system an my configurations is very powerful. It also supports millions of colors with Konsole, so it's nice when reading code.
- rcfox 6y agoIf you use the Emacs server/client, then it is very fast to open a file from the command line. But I prefer to just open files from within Emacs. With ido-find-file, I get fuzzy path matching, which makes it fast to find whatever. Rather than worrying about startup times, I'd have them work on including a lean set of quality of life extensions by default, like ido.
- dfabulich 6y ago1) I bet Stallman's never used ido. 2) You already use Emacs. What would it take to get a new user to use it? It would have to be installed by default, and be the quickest and easiest way to edit a file. That means startup performance.
- fhennig 6y ago> That means startup performance. Or the server/client setup could just be the default and the server starts at system boot.
- dfabulich 6y agoLinux distros aren't going to install an Emacs daemon by default.
- catalogia 6y agoLast I checked, they don't have full installs of vim either. So either way you're going to be installing a package (which is hardly a great ordeal...)
- tome 6y agoCan you do that for all users? The server is a per-user server, isn't it?
- empthought 6y agoStallman hasn't been in charge of Emacs for over a decade.
- dan-robertson 6y agoEmacs itself starts fast. Most people who use emacs have a lot of packages that load on startup or autoload files that need to be read and this makes startup slow. Maybe if saving an image were easier then things would be faster but I think most serious users don’t care because they start emacs once a week
- dfabulich 6y agoOut of the box, Emacs is slower than vim, and this is part of the reason why Emacs isn't installed by default on distros. Serious users don't care about startup performance, but that helps to explain why Emacs isn't gaining new users. Emacs isn't the quickest and easiest way to edit a file.
- matthewbauer 6y agoIs a second vs. a half second much of a difference? I think users start noticing at about 5 seconds.
- j88439h84 6y agoI use vim for quick tasks because of the difference in startup time
- Gollapalli 6y agoUsers start noticing ~200 ms. A full second is huge.
- madhadron 6y agoYou're repeating this in several places, and it's not true. See my comment about POSIX above.
- wglb 6y agoIf my emacs is a slow start, it is because I have a lot of previously opened files that it reads at startup. Otherwise, it is as quick as anything.
- throwaway_pdp09 6y agoAnd no actual timings eh? My emacs starts up within 3 seconds. 2 seconds of that is it reopening all the files from my last session and arranging them on screen, saving me quite a few more seconds of doing it manually. > my #1 goal would be to beat Vim on startup time You have some weird priorities > Stallman is too far out of touch ... but even with active users of Emacs FUD! He monitors the emacs bugs list. Also I just 2 days ago got a response from him personally regarding emacs. Note: personally. No credibility for you, sunshine.
- melq 6y agoI agree on the start up time point. I don't know how slow most people's experience is, and I don't use emacs, but I really can't imagine people aren't using emacs because of a few extra seconds it takes to open your code. To your second, rather obnoxious point: when they said 'out of touch', they didn't mean 'hasn't been in communication'. They meant he doesn't understand the attitudes/motivations/requirements of the community.
- throwaway_pdp09 6y ago> They meant he doesn't understand the attitudes/motivations/requirements of the community IME the emacs devs are very considerate of requests so I have to disagree. Edit: by contrast have you ever tried reporting a bug to microsoft? Something non-trivial. I have and it was just a wall of indifference.
- macintux 6y agoIs there a reason you’re so actively hostile in this thread? You’ve been belittling people in nearly every comment. You were willing to apologize to well-known contributors, but everyone else can stuff it?
- throwaway_pdp09 6y agoYes and no. I need to tone it down (or leave HN, wehich is probably better). Other people need to improve things. But this is not going to happen. An alternative to doing something is to dismiss other people's work. That's what this guy did. 'Emacs is too slow' - emacs startup time doesn't bother me, even if it did it would be down in the noise amongst other emacs irritations (or other software, heck, the amount of time I've wasted on Git...) He dissed emacs for no good reason, and dissed stallman who I really do respect (because RMS actually did something). I've seen a lot of this kind of destructive behaviour and I'm so tired of it. I should just leave HN if I can't contribute properly. Edit. If I post stuff like "x != y" I will say why, with timing, or clarify with In My Experience" or something. "emacs is slower" doesn't tell me by how much or discuss if startup time even matters, so it is a useless criticism; I can't act on it. It doesn't even feel like a good-faith comment.
- catalogia 6y agoSwitching from vim to emacs was a virtually seamless experience and a complete no-brainer... yet I put it off for years. Years before I finally took the plunge, I knew I eventually would. Vimscript is awful and although elisp isn't a great lisp dialect, it doesn't have to be great to be better than vimscript (which is abominable.) I shouldn't have put off the switch for so long. In retrospect I'm not even sure why I put it off for so long. > If I were working on Emacs, my #1 goal would be to beat Vim on startup time- With emacsclient, I don't think this is relevant. Concern about startup time certainly wasn't part of the reason why I put off switching for so long.
- dfabulich 6y agoYou put off learning Emacs partly because you learned Vim first. But why did you learn Vim first? Because people around you were already using Vim. Because Vim came preinstalled. Because Vim was quicker and easier to just edit a file. Startup performance isn't about persuading fence sitters. It's about becoming the default, the option people pick without even knowing why they picked it.
- catalogia 6y agoIn truth when I was a teenager I sat down with vim and emacs one afternoon and tried both. At the end of that day I chose vim, because I preferred the default bindings of vim. Nobody around me used either, nobody around me programmed at all, but I had read online that the pros used or or the other.
- zozbot234 6y ago> its reputation for "bloat." Eight Megs And Constantly Swapping. ;-)
- raverbashing 6y agoVim might be hard, but besides jokes about "how to quit it", it makes much more sense than Emacs. Emacs key combinations are weird. Discoverability is low. Even Vim will now tell you how to quit if you Ctrl-C it. Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x Ctrl-c). Some things are actually interesting and it tries to help at first but then it goes back quickly into emacs-babble that doesn't help much. The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal. I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
- chairfield 6y ago> The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal. That, and the power of its keybindings. > I don't see many reasons to learn Emacs when VSC, Atom or other editors exist. I think evil-mode, org-mode, dired, and magit, make a pretty compelling case for Emacs to fit into many programmer's workflows, even if it doesn't displace their code editor or IDE outright. Though even setting up just those packages requires quite a bit of configuration.
- fhennig 6y ago> Vim might be hard, but [...] it makes much more sense than Emacs. Counter-point: I think emacs makes much more sense. If you start it, you can navigate a file by clicking in places. It is a GUI application, whereas I think vim is just a terminal program by default? Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable (type Ctrl+h ? and it shows you a lot of commands you can use to find out about what functions a chord invokes or how to invoke a function with a key cord). With helm you just type a part of a function and it gives you a list of suggestions. Within programming languages I think auto-completion is a must-have for discoverability. Otherwise I have to constantly look up stuff in the documentation. And for that company-mode is really nice, I don't know about the vim side of it but I think something like that goes against the philosophy of vim as I understand it? To me, modal editing didn't make much sense in the beginning and for emacs the learning curve seemed less steep, so that's what I went with in the end. But clearly it must be good somehow, because so many people use and love vim! It's just not for me I guess.
- deleted 6y ago[deleted]
- cat199 6y agoso - your 1st point of reference is vscode which is an electron app, and then you diverge getting into emacs startup time and emacs reputation for 'bloat' this reputation by the way was 'earned' when entire computers had less memory than a typical emacs or vscode instance, and similarly, emacs likely currently uses less RAM than vscode due to afformentioned electron. Also: vi vs emacs 'bloat' wars were in reference to actual vi, not vim, which basically has the same non-core functionality as emacs (e.g. GUI widgets, editor-hosted scripting language) that was the basis for the original 'bloat' argument. this is not very coherent.
- dfabulich 6y agoI agree that VS Code is even more "bloated" than Emacs, but it has a multi-billion dollar corporation funding it. If Emacs could get that, maybe Emacs would be as popular as VS Code! But, short of that, Emacs can't beat VS Code. Emacs could beat Vim, but only by being so fast and small that it gets installed by default on Linux distros (and macOS and WSL). But that'll never happen, because Emacs folks prioritize features over performance. (If they cared that much about performance, they wouldn't be Emacs users!)
- acomar 6y agohonestly, with lsp-mode, it's pretty dang close to vscode, at least for the languages I care about. and the benefits of evil + a fully configurable editor are too much to pass up. a drop-in replacement for newcomers? no way. but if a powerful environment is valuable for you, like say if you spend a lot of time in an IDE and the shell, emacs's ability to integrate those things and a lot more is too good to pass up.
- chewxy 6y agoI found lsp-mode to be quite cool (recently reformatted my machine, and so decided to modernize). lsp-ui + company mode kills the input latency on any 4k display on Ubuntu tho. Input latency is now VS-Code/Atom level slow. Unbearable. Even with delay set to 0
- acomar 6y agoThis is much, much better on Emacs 27 with native json parsing. Once the language server is fully loaded (which can take a little while sometimes), input lag becomes insignificant again. Strongly recommend upgrading.
- chewxy 6y agoMine's GNU Emacs 27.0.91 (build 1). Thinking of switching to gccemacs for the native elisp goodness. But way too much yak shaving has been done already. I just disabled lsp-ui and lsp-company and all good.
- tsimionescu 6y agoAs a regular emacs user, I can tell you that start-up time is one of the lowest things on my priority list of things that I wish would be improved. Emacs is not vim. Emacs is not designed to be a program you open for every file. Emacs is and IDE. You open it every time your computer starts, and then you go to Emacs and find files from there. Occasionally, you'll have a file and want to look at it, and then you'll use client mode to have it open in a new buffer in your already opened Emacs window/terminal. I do agree that this is not the way anyone starting out would use a text editor. But if this way of using it is not comfortable to you, you'll be fighting so much of emacs that you really will have a miserable experience, regardless of startup time. Just to hammer the point home, normally if I connect to a Linux system and want to edit a config file, I would do the following: either `sudo vim /etc/hosts` or `emacs` and `C-x C-f /sudo::/etc/hosts`. I don't think too many people would run `sudo emacs /etc/hosts`.
- dfabulich 6y agoWe agree completely. Neither Emacs users nor developers care about start-up time or size on disk. And that's why Vim is installed by default on Linux distros (and macOS and WSL) and Emacs isn't. And that's partly why people learn Vim before they learn Emacs.
- madhadron 6y agoNot quite. vim is installed because vi is required by the POSIX standard and vim is the GNU version of vi. For the same reason, ed is still installed by default. It has nothing to do with popularity.
- ookdatnog 6y agoI currently use Emacs (with Vim keybindings) as my main editor, after oscillating between Emacs and Vim for quite a while. I think the biggest disadvantage Emacs has compared to Vim is its out-of-the-box experience. For me at least, I would say that learning to love Emacs takes a lot of effort, far more than it should. I think folks tend to mentally categorize Vim in the same basket, but I think Emacs is far, far worse at onboarding its users. The Vim out-of-the-box experience is not exactly great (crucial features like vim-surround have to be installed as a plugin, for instance, in the terminal version there's a lot of delay on some commands, etc). But while learning the unfamiliar keybindings initially takes effort, the huge speed advantage of modal editing becomes apparent after just a few days of sticking with it, and it becomes second nature surprisingly fast, to the point where you just stop considering editors which don't have decent Vim emulation. So while I wouldn't exactly describe Vim as accessible, it gets its core idea across fairly quickly. By comparison (and also in absolute terms), the Emacs out-of-the-box experience is horribly bad, it seems to make no effort to wow its first time users. It stubbornly sticks to a keybindings scheme that is unfamiliar to a modern audience and which, crucially, unlike Vim's keybindings offers no substantial productivity boost. All the documentation even still calls the Alt key "Meta". So you spend multiple days getting used to Emacs' keybindings scheme, only to end up roughly where you started (not much faster than before). At this point it's easy to start feeling like learning Emacs is not worth it: you've just spent days learning without your productivity increasing, and you just have to take people's word for it that, no, really, it'll get better. The main selling point of Emacs is its extendability. But this point is lost on users who aren't already convinced that they love and want to use your editor. You have to provide a good out-of-the-box experience still.