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

31–40 of 154 posts

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

#31

Post by skissane »

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…

> 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. Their contents may differ, and one may exist without the other.

Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs. (Unlike Emacs, vim doesn't have the "frame" concept, because vim doesn't appear to support multiple GUI windows.)

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

#32

Post by p2t2p »

thomastjeffery wrote: post #30
turminal wrote: post #24

Earlier quoted context omitted.

Neovim is not a rewrite.

No, but it tackles the same aforementioned issues: > opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. The main goal of NeoVim is to ditch the backwards compatibility and simplify the codebase. Sure, it isn't a from-scratch rewrite, but it's a very deep fork.

The magic of it is it just keeps on working. All those big changes didn't cause any instability for even once.

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

#33

Post by thomastjeffery »

dan-robertson wrote: post #23

I’m not convinced emacs performance is that bad. It’s pretty highly optimised for typing at a normal rate though I agree the data structures aren’t great for more graphical things (lots of properties, random access inserts, even just long lines). But then the way to improve this is to improve the data structures rather than replacing emacs lisp. Emacs performs better than many other applications at important objectiv…

> I’m not convinced emacs performance is that bad.

In my experience with modern hardware - a gaming PC - Emacs is noticeably sluggish compared to most other editors in a few specific ways: particularly syntax highlighting. When is the last time you used a different editor?

> whatever happened to remacs?

It's still there: https://github.com/remacs/remacs/wiki/Progress

As far as I can tell, its goal isn't to change anything about the core design though; just to re-implement the core in Rust.

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

#34

Post by qbasic_forever »

turminal wrote: post #24
_peeley wrote: post #6

I see a lot of parallels between Emacs' problems now and Vim's problems a few years ago: opaque maintenance/contributions, poor performance inherited from core design decisions made decades ago, the burden of backwards compatibility for legacy systems, etc. I think Emacs users and the community would benefit from a ground-up modern rewrite much like Neovim did for Vim, especially compared to this project which adds e…

Neovim is not a rewrite.

The upcoming 0.5 release will feel like a rewrite to some folks though, the entire config system is Lua-first right down to support of an init.lua instead of init.vim in vimscript. I've been converting my setup over to Lua and it's so much more understandable and sane vs. some bespoke scripting language that made more sense in 1990.

(it should also be mentioned the old vimscript support isn't going away, you can still use old configs)

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

#36

Post by matthewbauer »

buescher wrote: post #35

I wonder how the performance compares to gccemacs, with its native code compilation of elisp. That would be the fair comparison. https://www.emacswiki.org/emacs/GccEmacs

The readme says it’s based off native-comp so I think compiled lisp stuff should be no worse than gccemacs.

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

#37

Post by Barrin92 »

dan-robertson wrote: post #23

I’m not convinced emacs performance is that bad. It’s pretty highly optimised for typing at a normal rate though I agree the data structures aren’t great for more graphical things (lots of properties, random access inserts, even just long lines). But then the way to improve this is to improve the data structures rather than replacing emacs lisp. Emacs performs better than many other applications at important objectiv…

one fundamental thing I run into fairly often is Emacs horrific performance on long lines. Not really an issue for code, but looking at large JSON or text files routinely almost crashes my Emacs.

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

#38

Post by singingfish »

janoc wrote: post #26
JasonFruit wrote: post #18

The Emacs community, like the Lisp community with which it overlaps, is very conservative, in the sense that it doesn't throw things away quickly or make huge changes lightly. For that reason, I'd be very surprised if this took off — even though it sounds like it would be mostly backwards-compatible. I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more la…

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…

Nah I don't use emacs cos I want lisp. I use it because it was the only thing that made any sense at all on the HP-UX machines I got access to back in 1993. A side effect of that is that emacs does everything I need (with a little bit of pandoc on the side), and I haven't had to learn anything new since.

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

#39

Post by soamv »

JasonFruit wrote: post #18

The Emacs community, like the Lisp community with which it overlaps, is very conservative, in the sense that it doesn't throw things away quickly or make huge changes lightly. For that reason, I'd be very surprised if this took off — even though it sounds like it would be mostly backwards-compatible. I think Emacs types would shy away from building JavaScript into their editor, having V8 be the engine, adding more la…

It's true that they're conservative, but there have been non-trivial forks in its history. If a fork proves itself by doing something significant that the original can't or won't, things can get interesting! I wouldn't write this one off so quickly.
Post reply on HN