Earlier quoted context omitted.
The Lisp code is not natively executed. Some features like memory management (garbage collection) are layered on top of the OS. The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems. The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...). etc.etc.
I never said the Lisp code was natively executed. I'm not sure where you got that idea. Let's just agree to disagree. We are talking past each other at this point. Best regards!
VS Code uses 13% CPU when idle due to blinking cursor rendering
571–580 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#572An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…
People don't complain that web IDEs are bloated and slow because they need a web browser
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#573Earlier quoted context omitted.
I was really looking forward to that write up, as well. Unfortunately, the author must have some rule about not breaking the fourth wall. Or they avoid softballed summaries?
I think a recursive n-gate situation would be delightful. Someone should make this happen.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#574Earlier quoted context omitted.
For me Emacs opens up in about 2 seconds and it's ready to go and print text input in scratch buffer. I am on 2015 MacBook Pro 13" with i5.
That's been my experience as well, although that's still too slow for my tastes as a vim user. But I definitely don't ever recall it being 8 seconds, that feels like either an exaggeration or someone working on a potato.
Haha, no. It depends on what you use Emacs for. Remember the old joke about Emacs being a great OS? The reality is that Emacs is a great computing environment for almost anything that deals with text and even for some completely unrelated things. If you want a cross-platform GUI then Emacs Lisp may be one of the choices available.
This caused "plugins" - Elisp applications - to flourish and over the years a lot of code was written. Long story short, I have ~640000 (not a typo) lines of Elisp in my ~/.emacs.d/ alone, not counting the built-in Elisp libraries. It takes time to load that much code, even if it's byte-compiled beforehand.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#575An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…
Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…
You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU.
> So it's a good job we're about to throw it all out and start again, eh folks?
Yes, by those of us who have been working on the same platform you claim to love, for the better part of a couple decades.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#576An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…
You know what would be fast for display updating, ncurses. I wonder why they didn't use that? If only we had an ncurses based text editor.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#577An internet points out that Hackernews' favorite text editor takes up more CPU than the average Hackernews would have had at their disposal 20 years ago just to make the cursor blink on and off. Hackernews circles the wagons to justify the stupid engineering design decisions behind said editor based solely on the fact that embedding a complete Web browser just to draw buttons and text fields "won" over any sensible G…
I see this argument against electron again and again. Sure, sometimes its overkill - I've seen tray notification apps built with it - but sometimes, it's not. Sure it's not as efficient as something written in .Net, but its a great, hassle free way to go cross platform. People don't complain that web IDEs are bloated and slow because they need a web browser
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#578Earlier quoted context omitted.
Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…
It's the GNOME style of development: as soon as a bug appears which takes effort to fix, mark it EWONTFIX, declare it to be a symptom of the inherent brokenness of the current stack, then burn the whole thing to the ground and start over. Don't even let that which was burned fertilize new growth; it is tainted and must be purged entirely.
As it were, GNOME's IDE (which I wrote) uses 0% CPU at idle.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#579Earlier quoted context omitted.
I'm glad at least we made fun of both sides. I really wish there was a good option for GUI toolkits. Nearly all are either too primitive to make more than freshmen college (or tenured physics professor) level work or asymptotically approach web browsers without all that tedious attention to improvement and accessibility.
Qt pretty much nails this balance, WPF isn't bad either. Both will run circles around browsers at rendering performance and are much less tedious to develop in unless you've only done web dev before.
That it's been relegated to boring internal only enterprise app development is pretty sad. I enjoyed working with it immensely.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#580Earlier quoted context omitted.
You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down
My whole point is that "most used" is a terrible, terrible metric for anything except for most used.