Hacker News Reader

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

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

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

Vim isn't a GNU project and is licensed under it's own GPL-compatible license (see: :h license)

Good correction. The most common GPL licensed vi clone, then.

Yes, we are probably in agreement on that point. We probably disagree on whether we should care about start-up time.

We probably also disagree on what exactly it means to learn Vim before learning Emacs. I've been using Vim as a console editor far before I knew Emacs existed, but I have no idea how to use Vim for anything more than basic editing. Choosing an editor to learn as your development environment (which is what I would consider 'learning Emacs/vim/etc' actually means) is unlikely to be a decision you take based on system defaults. You are far more likely to learn the editor/IDE that your mentors use, whether that is Vim or Emacs or, as was my case originally, Borland Turbo C. Alternatively, when you are experienced enough to make a conscious choice of editor to invest in learning and customizing, your criteria will be more varied, but still likely not depend that much on system defaults.

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

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

Stallman hasn't been in charge of Emacs for over a decade.

> That means startup performance.

Or the server/client setup could just be the default and the server starts at system boot.

Linux distros aren't going to install an Emacs daemon by default.

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

Can you do that for all users? The server is a per-user server, isn't it?

Startup performance problems can be sidestepped with emacs daemon mode, at least in some cases.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Em...

https://www.emacswiki.org/emacs/EmacsAsDaemon

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

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

Yes, in the XEmacs case it is the case, not necessarily when you're using it like VIM

(There are gui versions of VIM as well but it feels weird)

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

Discoverability shoots up really higher than Vim or any tool when you use helm's M-x.

Also there is documentaion for literally all the key bindings and all the functions. You can access the code for all the functions. Emacs is much more user friendly than Vim.

vim sucks too but its ubiquitous from smallest container build to IoT device.

You're confusing vim with vi. On an IoT device I'd expect to find busybox's vi implementation. Definitely not vim. Ditto for containers, either a vi implementation instead of vim, or "vim-minimal" at the most. Not a full vim install.

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

Emacs 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

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

You're repeating this in several places, and it's not true. See my comment about POSIX above.

Is a second vs. a half second much of a difference? I think users start noticing at about 5 seconds.

Users start noticing ~200 ms. A full second is huge.

I use vim for quick tasks because of the difference in startup time

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

Interesting. How did you get it to store the list of previously opened files?

In the Emacs manual, read the "Saving Emacs Sessions" chapter (or get there from the 'desktop-save-mode' function documentation). Emacs can save and restore your current session, with opened files and windows layout, and as usual it's highly configurable.

By default it uses a global session context, but for example I configure mine to save the session locally in the directory where emacs is started. Then I can have several projects in parallel, and when I start emacs in the project top level directory it restores the session for this specific project. I also make the session saving file name machine specific, and ignored by unison for file synchronization. So the layout is specific for each machines with possible different screen setup leading to different window organizations. Just an example, you can tune it to fit your own needs --- that's the whole point of Emacs to me.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Sa...

What 'yaantc and 'rataata_jr said in this thread.

Not only does the desktop session remember and re-open the files, but it also remembers what frames you had open, what position on the screen and which screen the windows are on.

It is a huge convenience.

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

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

-Q shouldn’t give you any better startup time than vanilla emacs.

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

nah, 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

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

I 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

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

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

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

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

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

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

I 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!)

> its reputation for "bloat."

Eight Megs And Constantly Swapping. ;-)

This is a scalable acronym. It was upgraded to Eighteen Megs at some point in the 90s. And Eighty in 2016.

Aside from the Eight Megs... I also recall:

* Eventually Mallocs All Computer Storage

* Emacs Makes A Computer Slow

emacs -Q opens instantaneously

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