Live data from Hacker News

Emacs-ng: Emacs with Deno runtime and TypeScript

github.com

61–70 of 154 posts

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

#61
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…

I like emacs, and I'm not a lisp wizard, but it's an amazing editor and sure it has problems (long lines can grind you, although I've never halted emacs even with gb single line files - I did have to kill buffers though, and there's probably other things, on the other hand, I did grind plenty of other editors with much less) but...

> Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows"

Well, as someone pointed out, buffers are buffers, files are files, why would your editor try to fool you regarding the fact that what you have in front of you is in a buffer (that might be persisted into a file) and not exactly a file? Every buffer tells you if it's pointing to some file...

Frames aren't windows. Like tabs in a browser aren't browsers or windows either?

> It has weird keyboard shortcuts.

Yeah, the worse part of it all is you can't even change them, right?

> Oh, but if you press another key in between, you get lost in clipboard madness.

Yeap sometimes that happens, on the other hand the times it doesn't and you can cycle through things in ways that are not easy to do in other editors is great.

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

This ties back to the ring design? You can switch the direction you're going with two key-strokes. Granted, if you change the buffer (outside of just navigating the ring or copying into buffer, save, etc) then it does get weird, but it's usually pretty consistent and useful. It's like having a step by step git to your inputs into the buffer.

But `this`, this, this: > I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness.

If the JS runtime, with the million of hours and $ poured into it to make it performant at the runtime engine, libraries and general language improvement, when compared to others created decades ago (and mostly voluntarily kept) didn't have an edge in some things, it would probably be the biggest facepalm in programming history ever.

Having said all this, I'm happy people keep experimenting and building stuff for others to use, even if in JS, or Rust, or Zig, or brainfuck.

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

#62
post #59
post #50

Earlier quoted context omitted.

This got me interested in other lisps, as well. Looks like sbcl gives (time (fib 40)) to be about 1.7 seconds on my machine. (Ryzen 5 3600x.) For lulz, I clocked a dumb loop version. (defun fib (n) (loop repeat n for a = 1 then b for b = 1 then c for c = (+ a b) finally (return a))) And... well, serves as an amusing reminder that tree recursion has its downsides. :D Edit: I confess the speed of the loop got me curiou…

Try BigInt in JS https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Apologies, I should have acknowledged there are ways to get around that today. My guess is most folks writing javascript are not aware of BigInt. And will only become so when it bites them.

Granted, this is also true of fixednum in common lisp. At least "biting you" with that should only be performance. (I can't think of many other ways for that one to get you.)

Edit: I should further ack that "getting around" it is as simple as adding "n" to one of the constants. So, it is nicely done.

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

#63
post #56

As an Emacs user, I just have no use for this, and I get the feeling most Emacs users won’t either.

I will add to this, that I also have no reason to forbid something like this. It is scratching an itch for those involved. Kudos on that, and best of luck with it. I just can't pretend this is solving a problem I have. :D

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

#64
post #58
post #53

Earlier quoted context omitted.

Chicken's default is fairly unoptimized; try higher optimization levels.

Oh dang...you're right $ csc -optimize-level 5 fib.scm $ time ./fib real 0m5.506s user 0m5.489s sys 0m0.010s I could get a few fractions of a second better playing with the stack size (4 MB was the best, 8 MB or above would segfault) $ csc -optimize-level 5 -stack-size 4m fib.scm $ time ./fib real 0m5.295s user 0m5.277s sys 0m0.011s Everything else was negligible or extremely varied.

Yep, to get beyond that you basically have to stop writing scheme and start writing a tortured variant of Chicken, for performance. ;)

I stopped writing Chicken scheme code a few years ago; it was fun due to the ease of interoperating with C, but I found Chibi a better fit for that niche eventually.

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

#65
post #60

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.

I think you're missing the point. Emacs is an editor that is tied to programmers, where most of its users are programmers. It's not a general purpose text editor.

And while MacOS as an operating system for general purpose usage has done incredibly well due to its intuitive design first approach when it comes to developers many have pointed "your users" have pointed out that its interface and philosophy is restricting.

> It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not a buffer.

But nothing in emacs says you can't open a file. Just that the contents once it's opened are in a buffer. But if you open files outside of emacs they'll be opened as independent windows. By the same token we shouldn't be able to have a window split in frames, because Word opens each file in a window? The naming is a necessity for disambiguation.

And in fact, the idea of what you have open is a file does introduce problems. How many people you know *ucked up because they didn't save changes? They afterwards learned the hard way what is a buffer that every program uses (even in photoshop, or other software) but didn't learn it's name, just that you should save it every N minutes...

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

#66
post #26

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…

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.

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

#67
post #60

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.

But who are your users?

I started using emacs back in the 1990s, when I was in high school; I actually started using it under OS/2 (as part of EMX), later switched to running it under Linux. I never had trouble with the concept or name "buffers". I just read the manual and the manual explains everything very clearly. (I really loved the GNU Emacs manual, it was a pleasure to read.) In more recent years, I've abandoned emacs completely for vim, but vim calls them buffers too. I am totally at home with a text editor with "buffers", and changing the name isn't going to make anything less confusing for me – if anything, the change is going to confuse me.

Tools like emacs and vim are not targeted at "ordinary" users. If a tool isn't aimed at "ordinary" users, it shouldn't be judged for not meeting their needs, since it was never trying to.

I even wrote a text editor myself (half-finished personal project, I've never released it publicly, don't know if I ever will, it was really just to prove to myself I could do it). And it has "buffers" too, because that is the concept and terminology I am comfortable with.

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

#68
post #55

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…

> 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.

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

#69
post #20

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…

If any, having Elisp support on Guile would have far more sense, and with a JIT and non-blocking IO Emacs would be usable enough even under a high subprocess load (cough, GNUs). I am not an Emacs user but I like Scheme (scm user here) under nvi, and a lot of people could profit from a Modern Guile based Emacs environment.

I'm not sure. Guile-Emacs has been talked about for ages but never materialized. Scheme is nice and all from a language purity sense, but emacs lisp just feels so very practical for its use case.

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

#70
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…

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.

> A side effect of that is that emacs does everything I need

I'm certain you're telling the truth. And I'm sure that's the case for a lot of old-timers emacs users. But I have the feeling it's less and less true.

People that have used emacs for a long time don't need anything else, so they don't want any change.

People for whom emacs doesn't cover everything want change, but clash against the first group of people (who have been there/contributed for longer), and in the end migrate somewhere else.

Post reply on HN