Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing GNU Emacs to Native Code (2020)

arxiv.org

Post reply on HN
Print view View original

101–110 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#101

Post by xvilka »

volta83 wrote: post #38
DDSDev wrote: post #6

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabiliti…

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

There were two attempts to solve that - Guile Emacs[1] and Common Lisp Emacs[2]. Sadly, both are effectively dead now.

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

[2] https://www.cliki.net/cl-emacs

Re: Bringing GNU Emacs to Native Code (2020)

#102

Post by LanternLight83 »

the_duke wrote: post #79
tejuis wrote: post #41

Earlier quoted context omitted.

There are number of things you can do to improve your situation. Obviously you should not have packages loaded that you don't rely use. There are also ways to perform "lazy" loading, so that memory image is minimal until a package is really needed. I'm not using this myself. My usage model is such that I only start one Emacs and use emacsclient to add files for editing from terminals. Emacs is running all the time (w…

My problem is really not the startup/loading time, but the regular stutters and long latency for input and commands. I need my editor to "feel" really smooth and instant during editing. Emacs just never gives me that experience. I think many long-time Emacs (and Jetbrains IDEs, for that matter) users just don't notice how laggy it is because they are so used to it, or are not very latency sensitive.

As a vim user who's transitioned to Emacs with evil, response latency just feels so much better in vim, and although I love and use the daemon-client tip, it misses that point.

Re: Bringing GNU Emacs to Native Code (2020)

#103

Post by da39a3ee »

da39a3ee wrote: post #87
ashton314 wrote: post #4

Earlier quoted context omitted.

I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project. Note: this was on an Intel mac; anyone with an M1 tried this yet? I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not…

brew install emacs-plus@28 --with-native-comp might be a more standard "easy" approach on MacOS.

TBH the emacs-plus install didn't work for me (the Emacs.app produced failed with `LSOpenURLsWithRole failed`), whereas build-emacs-for-macos did work.

Re: Bringing GNU Emacs to Native Code (2020)

#104

Post by kkylin »

da39a3ee wrote: post #87
ashton314 wrote: post #4

Earlier quoted context omitted.

I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project. Note: this was on an Intel mac; anyone with an M1 tried this yet? I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not…

brew install emacs-plus@28 --with-native-comp might be a more standard "easy" approach on MacOS.

I suppose

brew tap d12frosted/emacs-plus

first? (I haven't tried it yet, and not sure I will.)

Re: Bringing GNU Emacs to Native Code (2020)

#105

Post by riffraff »

jonnycomputer wrote: post #93
riffraff wrote: post #90

Earlier quoted context omitted.

I think you want to do port install emacs-devel +nativecomp or port install emacs-app-devel +nativecomp

I did this last night. It failed to compile. OSX 10.14. Frustratingly.

I'm on macOS 11.2.3 (20D91) and it worked fine, though it took a while to compile since there were no binaries.

You may try to report a bug[0] for Mojave but I wouldn't hold my breath.

[0] https://trac.macports.org/wiki/MojaveProblems

Re: Bringing GNU Emacs to Native Code (2020)

#106

Post by stjohnswarts »

agumonkey wrote: post #74
geokon wrote: post #50

Earlier quoted context omitted.

last I tried VSCode there was a noticeable input lag (keystroke to character on screen). Is there some trick to fix this? I found it incredibly distracting. In Emacs... Magit is instantaneous while orgmode tangle/export is embarrassingly slow - but never a dealbreaker anecdotally eshell has some of the lowest latencies as well https://danluu.com/term-latency/

I couldn't even type 2 chars in vscode on a 2nd gen i5. To be fair it's been decades since I've experienced that amount of delay. Thanks I guess

If you're have a problem with performance in vscode 95/100 times it's memory not cpu bound. Obviously emacs uses less memory than vscode, at least at base configuration.

Re: Bringing GNU Emacs to Native Code (2020)

#107

Post by stjohnswarts »

the_duke wrote: post #18

Every time I try Emacs I get annoyed by it's slowness and go back to vim and VS Code. This might entice me to build it and try out my Emacs Doom setup again.

Try doom emacs and see what you think. I don't use it, I prefer pretty GUIs (I don't care what the HN crowd thinks of me and my love of graphics) but sometimes I'm in a terminal and DOOM emacs works great.

Re: Bringing GNU Emacs to Native Code (2020)

#108

Post by stjohnswarts »

lasagnaphil wrote: post #57
the_duke wrote: post #18

Every time I try Emacs I get annoyed by it's slowness and go back to vim and VS Code. This might entice me to build it and try out my Emacs Doom setup again.

It’s quite strange that the reputation for Emacs being slow hasn’t changed in decades even though hardware has advanced significantly...

Probably because it's relative. Emacs being single-threaded hurts it the most I think.

Re: Bringing GNU Emacs to Native Code (2020)

#109

Post by cjaybo »

zucker42 wrote: post #95
volta83 wrote: post #38

Earlier quoted context omitted.

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

> All this stuff runs in the UI thread. Braindamaged. Calling this "braindamaged" is hardly fair; I'm sure this decision was made ~35 years ago when it made more sense.

Forgive my ignorance, but why would doing all of the application work on a single thread make more sense 35 years ago?

Re: Bringing GNU Emacs to Native Code (2020)

#110

Post by cjaybo »

dw-im-here wrote: post #71
cjohansson wrote: post #51

Earlier quoted context omitted.

I agree about this issue, maybe in the distant future this could be fixed as well but where will VSCode be at that stage? Probably even more miles ahead, due to MS funding. When there is good async support in Emacs a lot of packages would need to be rewritten. However I prefer Emacs anyday over VSCode, I am very productive in Emacs because I'm used to doing almost everything in it

vscode doesn't even support multiple monitors, it's far behind in many areas.

What does it mean for an editor to "support multiple monitors?"
Post reply on HN