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

Emacs-ng: Emacs with Deno runtime and TypeScript

github.com

Post reply on HN
Print view View original

111–120 of 154 posts

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#111

Post by hvis »

toomim wrote: post #29

I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly oblitera…

> Emacs also has an "undo", but no "redo" command

They don't have default bindings (unfortunate), but try installing a recent build of Emacs 28 and binding these commands to the keys of your choice:

- undo-only

- undo-redo

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#112

Post by blacktriangle »

celeritascelery wrote: post #68
bitwize wrote: post #55

Earlier quoted context omitted.

> I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more layers of abstraction to understand and maintain, and splitting the extensions between Emacs Lisp and JavaScript. I'm also not convinced that a significant part of the community really wants this. I'm reminded of when an old C hand tells me that Rust will never replace C because it's too complex, brit…

> Much of computing in the very near future will be built on two languages: Rust and JavaScript. It will be interesting to see if this prediction pans out. There have been similar predictions about C++, Java, TCL, php, Perl, etc. it seems “the one true language” never emerges, but it is just around the corner. Though I really hope the future is more polyglot, because that is just way more fun.

Am I the only one that thinks JavaScript is living on borrowed time? Once webasm matures and has a consistent story for DOM interop, JS will lose its status as the language we all have to know and be forced to compete head to head based on its merits. I wouldn't bet on JS in that scenario.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#113

Post by blacktriangle »

bitwize wrote: post #60
skissane wrote: post #31

Earlier quoted context omitted.

> But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". Using "buffer" as a name for text being edited is hardly worthy of the title weird , vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. The…

> Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other. It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not…

Meet your users where they are is great advice for consumer apps you want people to onboard to quickly and the users only interact with them periodiclly.

We're talking about the power tools of our profession. Nobody designs a band-saw to meet their users where they are either. These are apps we spend 8hrs+ per day living in, and frankly the buffer wording is superior because a buffer is not a file, but a file is in a buffer.

Meeting your users where they are is how we got everybody moving from Textmate to Atom and now to VSCode as the new hotness that would finally kill Emacs and vi. And yet that's the mentality that prevented those newer editors from having the legs to really last. Meanwhile other power tools like Eclipse which absolutely meet nobody where they are are going strong too.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#114

Post by anthk »

Ar-Curunir wrote: post #104
anthk wrote: post #91

Earlier quoted context omitted.

These people are delusional, they think they can do low level device driver thinkering with just JS... Eh, no. Not even close . Back in the day I wrote a personal patch for BTTV in order to support my video card with different tuner and radio settings. It was damn hard for a C newbie like me. For these people it would be a nightmare.

Yeah, and now imagine if you didn’t have to worry about simple things like memory safety or overflow or null pointer checks or so many C problems that Rust fixes. The point of Rust is to enable newbies to write systems software.

>That's what Go has been built for, but if you trust a newbie writting low level stuff, bad shit will happen either sooner or later.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#115

Post by anthk »

achempion wrote: post #66
janoc wrote: post #26

Earlier quoted context omitted.

Well, basically this is someone trying to implement VSCode in Emacs ... Ain't gonna get far once the main developer loses interest in the project. Emacs users use Emacs because they want Lisp and don't care about web rendering and javascript runtimes ... Oh yeah and Rust is thrown in too for good measure. Good 90% of Emacs code is in the extensions which are in Lisp and nobody is going to rewrite them to Javascript e…

Emacs speed was good enough 45 years ago, with modern processors it's just lightning fast. You can have C / Rust / any_lang extensions like RipGrep to boost some intensive workloads as well.

>Emacs speed was good enough 45 years ago

Uh, in the age of the 386 and 4MB of RAM, if you had that setup against a 486 an 8MB, you chose between running X and running Emacs. OFC you could run jmacs perfectly.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#116

Post by throwanem »

hvis wrote: post #109
throwanem wrote: post #48

Earlier quoted context omitted.

You're underplaying your hand, you know. Why leave out that cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else, and can't be rebound to match muscle memory in any way that's really useful? I mean - if you're going to ignore everything that makes Emacs great on your way to cavil about how it's different, why not go all out, right?

> cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else Try `C-w`, `C-k` and `C-y` inside a Bash shell sometime, you might be surprised. `M-w` is an exception, though.

Oh, interesting. I knew about C-s and C-r there, and knew C-k as kill to end of line, but didn't know yank worked there too - thanks for the tip!

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#117

Post by slightwinder »

I'm curios, if this has direct TypeScript-Support, does this mean it can use VS Code-Parts and Plugins? Effortless plugin-installation would be a killerfeature... Similar advantage could become direct reuse of VS Code-Parts, like the code for language servers or the monaco editor-part.

This could unfold into a project which demand relativ little work, while pushing it to a level where it can compare with VS Code. It could become a good bridge beween modern VS Code and old GNU Emacs that way.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#118

Post by outworlder »

slightwinder wrote: post #117

I'm curios, if this has direct TypeScript-Support, does this mean it can use VS Code-Parts and Plugins? Effortless plugin-installation would be a killerfeature... Similar advantage could become direct reuse of VS Code-Parts, like the code for language servers or the monaco editor-part. This could unfold into a project which demand relativ little work, while pushing it to a level where it can compare with VS Code. It…

> Effortless plugin-installation would be a killerfeature

How is that different from what Emacs package managers provide?

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#119

Post by outworlder »

shadowgovt wrote: post #49
toomim wrote: post #29

I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly oblitera…

it is fascinating to see how (particularly in older software / systems) radically different decisions were made about what is nowadays considered "fundamental" UX, and to imagine what the world would have been like if this other thing happened to become the consensus standard. Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute spac…

> Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI.

When did you last start Blender? This used to be true. Nowadays it's at least on par with commercial tools if not better.

Re: Emacs-ng: Emacs with Deno runtime and TypeScript

#120

Post by bitwize »

blacktriangle wrote: post #113
bitwize wrote: post #60

Earlier quoted context omitted.

> Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other. It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not…

Meet your users where they are is great advice for consumer apps you want people to onboard to quickly and the users only interact with them periodiclly. We're talking about the power tools of our profession. Nobody designs a band-saw to meet their users where they are either. These are apps we spend 8hrs+ per day living in, and frankly the buffer wording is superior because a buffer is not a file, but a file is in a…

> Meeting your users where they are is how we got everybody moving from Textmate to Atom and now to VSCode as the new hotness that would finally kill Emacs and vi. And yet that's the mentality that prevented those newer editors from having the legs to really last.

I'd like to think that too, but the sad fact is that most developers these days use VSCode. It is the new hotness that killed Emacs and vi. Emacs and vi are both mere footnotes compared to VSCode in terms of market and mind share, and even Eclipse has been largely supplanted within its niche by the far easier IntelliJ suite.

I suppose vi and Emacs will be around as long as they have diehards still using them, but they're not capturing new users' hearts and minds like they used to. Most professional developers I've met hear Emacs and think it's something that last ran on dusty old DEC iron -- and that includes people who worked at DEC in the 80s! The fact that Emacs is still maintained and runs on modern systems came as a genuine surprise to them.

Emacs and vi held on for as long as they did because there was a significant contingent of developers and technical people still familiar with a traditional Unix environment up until the 2000s or so. As some of these people aged out of the work force, they were replaced by an even larger contingent of younger developers, who only ever grew up with Windows and Mac, and have a reasonable expectation that programs work the Windows and Mac way. By and large they don't even have much interest in Linux on the desktop. Linux is for servers/the cloud. Their dev workstation is a Mac. And Emacs and vi are relics from the before times, whose 1970s UIs just aren't worth grappling with because there are better options available. Those are the people Emacs has to reach if it is to stay relevant. Which means that one way or another it will be "modernized" whether we like it or not.

Post reply on HN