88 comments

[ 3.5 ms ] story [ 110 ms ] thread
I'd love to see an atom package for this.
Should add a surreptitious cryptocurrency miner to keep your cpu/gpu warm and cozy.
I think emacs already does that fine
And it doesn't even use electron. It was just ahead of time.
Not without better concurrency support.
I know about ram and don't have a computer handy but processor too?
have you actually used emacs on a cpu made in the last 20 years and found it to be slow?

compared to vim or bash, it is cpu intensive. compared to any of the graphical apps that come with a mac, it is easier on the cpu (and on RAM).

have you actually used emacs on a cpu made in the last 20 years and found it to be slow?

Yes. Early 2015 Macbook Pro.

It's hella slow to start up, of course, even on my 2017 mbp. Chugs when scrolling depending on active modes, too.
Launch it as a daemon and instantly connect via emacsclient.
I should do that, but it seems like a Band-Aid solution to the real problem which is poor performance.
Launching `emacs -Q` (=no daemon, start without init.el) – which is equivalent to a typical way of starting `vi` or (shudder) `nano` – opens essentially instantly. A more complicated init.el/.emacs will take longer to start, but I fail to see how this is 'poor performance'.
Emacs is meant to be open all the time. As it is way more than a simple Editor.

You can do all the CLI tasks inside Emacs.

Emacs Vanilla takes less than a second to open in my t430(2011)

I use emacs basically all day and so my comment was partially in jest. I find the following things to be slow:

1. Large files

2. Anything synchronous and blocking that takes a little too long can be frustratingly slow. This often isn’t entirely the fault of emacs (e.g. if it is slow because an external program is slow) but async isn’t done for everything so sometimes things block and you can’t do anything while they are working. This is particularly annoying if the external program provides eg auto-completion

3. Running a macro a large number of times

4. Building the completion list when finding files (I think this is a combination of an issue with the extension for finding files and how it reads a directory and just reading a very large directory over nfs)

5. Sometimes it becomes slow enough that the visual lag between key press and character-on-screen is annoyingly large

we used to call it: Eight Megabytes And Currently Swapping. but those days are long gone...
Compared to VS Code? Come now.
Spacemacs with a mostly standard config has similar load times as VSCode (2-3 seconds)...
I’ve never understood the load time argument about IDEs, I probably restart my IDE whenever I do os upgrades every other week or so. This is true when I use IntelliJ, Emacs, or VS Code. Any of these could take 30s or longer to start for all I care.

The issue with VS Code is that it’s more memory hungry than google chrome. More than once I’ve caught it using half a gig of memory, with various instances of flow using up to a gig on top of that.

I prefer using one editor for every task. This means both coding and quick config edits or jotting down notes. So while I often keep an instance up for hours, I also open and close it frequently enough that load time is enough of an issue.
I personally do not use one editor for everything. To each their own.

Emacsclient would solve this issue for you though.

Vim solves this issue for me, since it loads nearly instantaneously even loaded down with plugins.
There's nothing standard about Spacemacs. It's a tremendously useful premade config, but it's not indicative of the performance of the Emacs environment.
I know, but featurewise it's on par with VSCode with things like git integration and auto-suggestion etc. so I feel like it's a fair comparison.

Do you think vanilla Emacs with the same amount of packages would be much faster (without getting into tricks like a daemon)?

and once again emacs proves its superiority to ...achem vi sucks achem. ;)
This holy war between emacs and vi(m) is toxic and HN is no such place for this.
Reminds me that my first program ever was probably typing the fire effect assembly demo..
Can I get a quick vim vs emacs usage vote here? Not looking for a war. Just a usage vote. I will try and update results. Feel free to reply with your daily hours too

Results below- small sample but makes me wonder about stack overflow survey about vim being thrice as used as emacs. I am a very loyal vim user but I would wager that those results were influenced by the occasional vim user. What are others thoughts on this?

2:52 UTC 9-7 vim-emacs

nano

:P

Nano just exists to fool my fingers with its quarter implementation of Emacs bindings, and I end up deleting half of the file's contents.
>> I end up deleting half of the file's contents.

Are you sure you're not using vim?

Nah, vim's modal. True, one of those modes is 'break everything', but the other mode is 'beeping furiously', so I generally notice I'm not in emacs pretty quickly.
Beeping is a feature. The user must be made aware that they are typing in vim, lest they start pressing random key combinations, like C-x, C-m etc.

It is well known that users may press these keys by mistake, while falling asleep on their keyboard. Therefore, vim beeps to keep them awake and avoid trouble.

Evil, best of both worlds :)
Vim is a text editor, emacs is more like an IDE for your OS that works best when lived in. So they aren’t exactly directly comparable.

But, +1 for emacs.

Indeed I use emacs for all "real" editing, but I use vim for composing emails - in my own console-based mail-client.
Does your DNS hosting solution allows for routing to least latency geographically closest host?
No.

It just lets you setup "standard" record-types, such as A, AAAA, MX, etc.

>makes me wonder about stack overflow survey about vim being thrice as used as emacs.

Your poll has more selection bias than the SO survey: your poll was seen only by HNers who decided to read comments on a story with "Emacs" in the title.

(comment deleted)
Correct, but given the lingering sense of the two editors being polar opposites, left behind from centuries-past flame wars of the internets, both vim and emacs users are likely to come forward, just to see what the fuss is about.
Emacs because of Org Mode.
Vim also supports org mode as well. Not quite as nice as emacs but it gets the job done for me
Syntax highlighting and basic outline support is not orgmode. Orgmode is an agenda, a smart task scheduler, a spaced repetition learning system, a publishing environment, a literate code tool, a knowledge base...
Vim.

Vim's command-line is more alien to the last 4 or 5 gui-bred younger generations of programmers. Learning to master it is therefore more of a badge of hounour, and for that, more sought-after, than learning to master Emacs.

Personally, I'd rather have Vim, but with Emacs-Lisp as a scripting language. That would rock.:x

> Personally, I'd rather have Vim, but with Emacs-Lisp as a scripting language. That would rock.:x

Spacemacs sounds like it’d fit your needs to a T. Or doom-emacs.

Those are Emacs configs and I do prefer vim, just with a different scripting language - but, thanks :)
> Personally, I'd rather have Vim, but with Emacs-Lisp as a scripting language

Vim does have a scheme language binding such that vimscript can call an embedded script written in scheme, and that scheme script can interface with vim. This is also the case for other languages like perl, python, ruby, tcl, and several other languages.

Emacs

(Vi is the God of editors, but Emacs is the editor of Gods.)

Emacs. Vi is awesome — it really is — and vim is neat too, but I prefer an entire operating environment. And Lisp. And man-centuries (man-millennia?) of usability improvements.
for the operating environment i prefer smalltalk. if only it (pharo/squeak) had a better editor.
vim (that brings the tally up to 15 for emacs, and 10 for vim)
I love it, feels warm.
Can I add this as a zone program in zone-mode?