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

121–130 of 154 posts

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

#121

Post by slightwinder »

outworlder wrote: post #118
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?

They are not really effortless, especially when distributions like doom or spacemacs are used. Sure, today it's easier than 10 years ago, but compared to the modern solutions it still pretty backward.

In VS Code you can search for ne plugins from inside the application (which emacs also allows), while also showing all information including pictures and animations about the plugin in-app (which emacs does not allow). VS Code also shows which bindings, functions and settings the plugin adds (in emacs only indirect possible, with effort).

And best part: it just works. With emacs there are always a gazzilion problems coming with plugins. Be it some conflict or just additional work neccessary to make it work. Thouhg this is mostly a solvable problem with emacs, it just does not get solved. The Emacs communities solultion for this is the usage of distributions, which come with other problems and have only support for the more popular plugins.

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

#122

Post by shadowgovt »

outworlder wrote: post #119
shadowgovt wrote: post #49

Earlier quoted context omitted.

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.

I use Blender all the time; it's a great tool. What I mean is that its default keybindings, UI manipulation metaphors, etc. are notably different from the applications that live closer to 3DSMax and Maya on the family tree of 3D editors.

* Moving an object in Blender: Select, press 'G', now the mouse floats the object without the need to hold a mouse button down, optionally hit 'x', 'y', or 'z' to constrain to those axes. You can also take advantage of the 3D cursor.

* Moving an object in 3DS Max: Select to bring up manipulation widgets, click and drag the image of the widgets to move the object.

Starting to learn Blender if you learned 3D scene creation in Max is like starting to use emacs if you learned word processing in Microsoft Word. The metaphors aren't categorically better or worse; they're very different.

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

#123

Post by cle »

dleslie wrote: post #52
cle wrote: post #45

Earlier quoted context omitted.

This doesn't require rewriting extensions, it is backwards compatible.

It does not improve elisp performance, however. So it's pointless for those who use and rely on elisp.

I don’t think that’s a fair characterization, you should be able to redefine widely-used Elisp functions to run in deno. One that immediately comes to mind is the crappy HTTP client that Emacs ships with. (I have not tried this, just speaking hypothetically.)

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

#124

Post by cle »

dleslie wrote: post #51
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…

And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.

While technically true, you can still improve performance of existing Elisp code by redefining certain commonly-used Elisp functions perform better in Deno.

Sure the Elisp bytecode itself doesn't evaluate faster, but that distinction isn't really important here. The end-to-end perf of certain functions can be improved in a backwards-compatible way.

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

#125

Post by vitus »

taeric wrote: post #106
anthk wrote: post #88

Earlier quoted context omitted.

>And... well, serves as an amusing reminder that tree recursion has its downsides. :D OFC I would rewrite that as a iterative form (and any Schemer here could :D), but here we are testing performance :D.

Agreed. I didn't mean that necessarily as a criticism of anything. Just hard to have an intuition for just how much it slows down. I suppose there is a bit of something in there about using the right algorithm. But I can understand picking one that will take time for comparing speed. I'm not sure either is really representative of work you expect an editor to do, though. Curse of benchmarks.

The speed of the naive recursive fib scales with the number it computes, which is roughly 1.6 ^ n (the eigenvalue of the matrix for the recurrence relation is the golden ratio, phi).

Intuition: if you were to expand and flatten the recursive calls, you'd end up with something like

(+ 1 0 1 1 0 1 1 0 ... 1 0)

with exactly (fib n) 1s (base case (fib 1)), and no more than (fib n) 0s (base case (fib 0)).

Simple example:

     (fib 3)
     = (+ (fib 2) (fib 1))
     = (+ (+ (fib 1) (fib 0)) 1)
     = (+ (+ 1 0) 1)
     = (+ 1 0 1)

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

#126

Post by vitus »

hvis wrote: post #110
vitus wrote: post #9

Earlier quoted context omitted.

EDIT: as pointed out, this is run with Guile 2.2, which is pre-JIT. Results to be posted later in this thread... Okay. $ cat fib.scm (define (fibonacci n) (if ( Node also uses V8. $ time node fib.js node fib.js 1.29s user 0.01s system 100% cpu 1.296 total But okay, you wanted deno. $ time deno run fib.js deno run fib.js 1.41s user 0.02s system 99% cpu 1.423 total Meanwhile, using `emacs --script fib.elc` to evaluate…

> Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s Which Emacs version is this? Any chance you want to try the native-comp branch and post its numbers here as well?

This was emacs 27.1 (which is the version in the Arch repo).

I can install native-comp via AUR. It'll take some time.

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

#127

Post by dleslie »

cle wrote: post #123
dleslie wrote: post #52

Earlier quoted context omitted.

It does not improve elisp performance, however. So it's pointless for those who use and rely on elisp.

I don’t think that’s a fair characterization, you should be able to redefine widely-used Elisp functions to run in deno. One that immediately comes to mind is the crappy HTTP client that Emacs ships with. (I have not tried this, just speaking hypothetically.)

... That still isn't an improvement of elisp speed. It might improve the performance of Emacs, but it's not improving the performance of elisp.

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

#128

Post by [deleted] »

cle wrote: post #124
dleslie wrote: post #51

Earlier quoted context omitted.

And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.

While technically true, you can still improve performance of existing Elisp code by redefining certain commonly-used Elisp functions perform better in Deno. Sure the Elisp bytecode itself doesn't evaluate faster, but that distinction isn't really important here. The end-to-end perf of certain functions can be improved in a backwards-compatible way.

[deleted]

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

#129

Post by dleslie »

cle wrote: post #124
dleslie wrote: post #51

Earlier quoted context omitted.

And let's not overlook that it doesn't make elisp any faster. This isn't going to have a performance improvement for those who use elisp regularly for productive reasons.

While technically true, you can still improve performance of existing Elisp code by redefining certain commonly-used Elisp functions perform better in Deno. Sure the Elisp bytecode itself doesn't evaluate faster, but that distinction isn't really important here. The end-to-end perf of certain functions can be improved in a backwards-compatible way.

If we're entertaining writing elisp methods in a faster language to improve overall performance, then it's already been done and being done via writing methods in C.

I don't see the point of polluting Emacs with Javascript.

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

#130

Post by vitus »

vitus wrote: post #126
hvis wrote: post #110

Earlier quoted context omitted.

> Meanwhile, using `emacs --script fib.elc` to evaluate byte-compiled (fib 40) takes about 32s Which Emacs version is this? Any chance you want to try the native-comp branch and post its numbers here as well?

This was emacs 27.1 (which is the version in the Arch repo). I can install native-comp via AUR. It'll take some time.

I think this is what you're looking for.

    time emacs --script fib-0b03fe9a-6b386e71.eln    
    emacs --script fib-0b03fe9a-6b386e71.eln  22.47s user 0.09s system 99% cpu 22.664 total
About 50% faster, which is nothing to sneeze at, but still appreciably slower than most other things I tried.

(I copied the .eln from the cache to confirm that's what I'm running against; I got a similar speedup from running against fib.elc.)

Post reply on HN