Hacker News Reader

Comment by komali2 | Hacker News Reader

I'm playing around with emacs, slowly trying to get it to feature parity with vscode to see if I could one day use it as a main editor. One thing I'm constantly surprised by is how slow random stuff is in emacs. Maybe my setup is fucked? But simple stuff like holding my "scroll down one line" macro is not smooth at all, the time it takes to get from launch to accepting commands is way higher than vscode, scrolling with the mousewheel is gross, and worst of all, there's input delay on text input. Maybe it's the chrome effect - vscode seems faster because it's hogging my ram? I wish I had checked the memory usage before posting this.

It's a shame because I like the idea of emacs, but I simply can't seem to get it anywhere near as good as vscode.

View on HN

I came the other way very recently (emacs to VSCode). It wasn't performance that was the issue, it was the level of effort required to get the same level of experience between VSCode and Emacs.

I have used Emacs for about 10 years, and have days upon days of effort invested in my emacs config. Despite this, it took 5 minutes of setup to get a significantly superior setup for the languages I'm using currently (Elixir, Rust, ReasonML, Python). I had more features available (e.g. better highlighting and listing of current errors), and the core ones like auto-complete and go-to-definition worked much more reliably. It took an hour of tweaking some keybindings and settings to remove some UI cruft and navigate between splits and I have something that performs at least as well as Emacs in every regard. It's only been a couple of weeks, but it's promising so far.

Nice to hear you've managed to get stuff you liked in emacs working in vscode, that's something I'm constantly tweaking as well. Mind sharing your vscode keybindings/settings.json?

Yes, please.

This doesn't seem right. I'm running it on a five year old computer and it feels way snappier than VSCode. I run on both Windows and OS X and don't have performance issues.

It could be some a rogue package or something with a wonky config?

Also, you should start it with emacsclient (I alias it to a shortcut). Run the emacs server/daemon in the background, and everytime you type your alias with a file name, it'll open almost instantly.

See more on the EmacsWiki page [1]

[1] https://www.emacswiki.org/emacs/EmacsClient

I went through some stack overflow again and a lot of people are suggesting it could be linum-mode? I have it on everywhere cause I like being able to jump to a line number. But I have emacs 26 which is supposed to have fast, C written linum mode.

The modern, Emacs 26+ mode is: display-line-numbers-mode. This (put in config) will enable it for you globally:

(global-display-line-numbers-mode 1)

linum mode (and the faster contrib, nlinum mode) were used prior to Emacs 26, and sometimes had some performance issues in large files.

Also, all of those are for displaying line numbers on the left margin. Jumping to a particular line in code works always.

(And if you want to go totally oldschool, use column-number-mode and line-number-mode to see the column and line numbers of your current position displayed in the modeline. Or (shameless plug) install nyan-mode ;).)

You don’t need linum-mode to jump to a line number. Just use M-g g, or M-g M-g.

To elaborate a little:

"M-x goto-line which is bound to M-g g, or M-g M-g."

Naming the function "goto-line" in full can make it easier to remember for a reader, providing a fallback for when the key-chord isn't part of muscle-memory yet, and provides an easy way to look up the binding in emacs itself:

C-h f <ctrl-h(elp)-f(unction)>

"Describe function:" goto-line

"[..] It is bound to M-g g, M-g M-g [..]"

`C-h k M-g g` (k for key) will also describe what the key-chord `M-g g` is bound to. Also, `C-h k` is bound to the function `describe-key`.

But how would I know the line number of what I wanna jump to without display line number on? I.e I'm on line 100, want to pop down to a function on 202 (a line I haven't visited yet).

Along with interactive search (C-s forwards, C-r backwards), you can jump to the definition of a symbol (including a function) with ‘M-.’. These would be the idiomatic ways of moving around. There are multiple ways of maintaining up-to-date symbols depending on your context, which you can look up in the documentation for ‘M-.’.

It'd probably be more common to jump, e.g. using ace-jump or plain old interactive search.

Some macros can be very slow but something simple should never be noticeably slower than in any other editor. But what does a macro do to scroll a single line?

About smoothness, maybe, but I don't have any editor to compare it with now, except vim. I remember that NetBeans, Eclipse and some JetBrains editor where not any different on my hardware last time I had to use them.

Startup time, it's a non issue for me because I start it up after boot and keep it running. I load files into it with emacsclient [1] and save the desktop to a file to pick up from where I was after a boot. Surely, with hundreds of buffers it takes a little to finish loading but I don't reboot every month.

[1] https://www.emacswiki.org/emacs/EmacsClient

> One thing I'm constantly surprised by is how slow random stuff is in emacs. Maybe my setup is fucked? But simple stuff like holding my "scroll down one line" macro is not smooth at all

That's super interesting, because the main reason I don't use VSCode at all is that whenever I hold down a key, it seems like the key events happen faster than the editor can handle, and it ends up continuing moving well after I've stopped pressing it (which is most annoying when it's the delete key).

In my experience this comes from fancy plugins that do work. ELisp sadly lacks parallelism. Emacs was for me an acquired taste

I put some serious effort into trying to use Emacs a few years ago and had the same experience. It's not so bad in the default configuration, but by the time you've installed enough LISP code to reach feature parity with modern editors it slows down annoyingly. Eclipse is noticeably faster.

> Eclipse is noticeably faster.

You definitely had something misconfigured then...

Not saying that's your problem, emacs could do a lot more to be friendlier to newcomers. I'm just saying, don't be so quick to judge it until you've gotten with your local emacs nerd to see what's wrong with your setup.

Are you an emacs nerd willing to peek? Maybe it's just spacemacs by definition is fucky, but my machine is a beast so I feel like other people would be complaining about slow spacemacs if that were the case and I can't find much of that out there.

init.el and .spacemacs: https://github.com/komali2/Configs/tree/master/emacs

Yeah it's spacemacs. Any soup to nuts emacs distribution like this is going to be slow. I experience it all the time in doom. You don't have anything misconfigured.

Features like helm, ivy, projectile, etc cost. Linters and autocomplete can really make emacs jank. All this stuff is configured out the gate in these distributions.

I've found that prelude, at least, isn't too bad, as long as it's not running on my phone.

I really like spacemacs (I'd love to get back to using vi keybindings in emacs), but man is it slow. Awfully cool, though.

I just took your config for a spin and it's actually quite snappy for me... What exactly is slow for you?

Are you using a prelude like Prelude, Doom or Spacemacs?

scrolling and mouse is probably not important in that culture; that said .. text input delay is super sad

Reply on news.ycombinator.com