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

Continued progress porting Emacs to Rust

db48x.net

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Continued progress porting Emacs to Rust

#11

Post by simias »

flurrything wrote: post #9
ealhad wrote: post #4

To anyone wondering why this might be a good idea, there are some interesting comments in a GitHub issue ( https://github.com/Wilfred/remacs/issues/305 ): > For users, I hope Remacs will be faster (it's easier to optimise), more robust (we have stronger type checks and the ability to add unit tests), better documented (see #262) and somewhat more featureful (we have some ideas for solving the dumper problem that woul…

> For users, I hope Remacs will be faster The main reason my emacs is painfully slow is that most elisp code blocks. Stuff like hitting tab for auto-completion might perform a blocking query from a language server hanging emacs for multiple seconds. Opening a file tries to start a language server and blocks the editor in the process. Etc. Making emacs itself faster won't make the experience of working with emacs any…

Some things like indenting a large file or even searching in a huge buffer can be quite slow. For instance I just tried indenting a ~1000line C buffer and it took about 2 seconds. When dealing with very large files (hundreds of MB) some basic movement and editing commands can be quite slow. Dealing with very large TAGS file (for the linux kernel for instance) is annoyingly laggy as well.

I agree that it's not the panacea though, Emacs would benefit from using a more threaded or event-oriented programming model for many things.

Re: Continued progress porting Emacs to Rust

#12

Post by mrec »

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true?

  Emacs will change how you think about programming.

  Emacs is an incremental programming environment. There's no 
  edit-compile-run cycle. There isn't even an edit-run cycle. You can 
  execute snippets of code and gradually turn them into a finished 
  project. There's no distinction between your editor and your 
  interpreter.
I'm assuming what it means is "Emacs will change how you think about programming Emacs Lisp". Which is a rather narrower proposition, and much less of an incentive to switch, since I doubt many non-Emacs users are particularly interested in programming Emacs Lisp.

Re: Continued progress porting Emacs to Rust

#13

Post by bachmeier »

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

My interpretation is that it's not a statement about writing code but running it. It's accurate IMO but probably not terribly important in the grand scheme of things.

> I doubt many non-Emacs users are particularly interested in programming Emacs Lisp

By definition, if you're programming Emacs Lisp, you're an Emacs user. Emacs is the interpreter.

Re: Continued progress porting Emacs to Rust

#14

Post by another-cuppa »

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

It is true. Learning any Lisp changes how you think about programming. Learning Emacs Lisp will make you wish all development was like that.

Re: Continued progress porting Emacs to Rust

#15

Post by ams6110 »

flurrything wrote: post #9
ealhad wrote: post #4

To anyone wondering why this might be a good idea, there are some interesting comments in a GitHub issue ( https://github.com/Wilfred/remacs/issues/305 ): > For users, I hope Remacs will be faster (it's easier to optimise), more robust (we have stronger type checks and the ability to add unit tests), better documented (see #262) and somewhat more featureful (we have some ideas for solving the dumper problem that woul…

> For users, I hope Remacs will be faster The main reason my emacs is painfully slow is that most elisp code blocks. Stuff like hitting tab for auto-completion might perform a blocking query from a language server hanging emacs for multiple seconds. Opening a file tries to start a language server and blocks the editor in the process. Etc. Making emacs itself faster won't make the experience of working with emacs any…

Emacs does block on many operations, but I've never had it be really noticeable on tab-completion type stuff.

Though I only use auto-complete on emacs commands, so maybe I've just missed it.

Re: Continued progress porting Emacs to Rust

#16

Post by tmountain »

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

Clojure + Cider inside of "Spacemacs" is the most enjoyable development environment I've used in over 20+ years of programming. It's amazing how quickly you can get stuff done.

Lisp changes how you think about programming. Emacs gives you the shortest path to a code/test feedback loop.

Re: Continued progress porting Emacs to Rust

#17

Post by rekado »

nerdponx wrote: post #6
wscott wrote: post #5

And there are related efforts to upgrade the lisp used in emacs to a more modern and standardized version. I think it is GuileEmacs I am remembering. I hope to two efforts are compatible.

My thinking as well. This is a golden opportunity to replace Elisp. Edit: Guile won't be used, because of the burden of contributing. https://github.com/Wilfred/remacs/issues/66#issuecomment-273...

This is very unfortunate. Emacs itself also requires copyright assignment, though, so if Remacs doesn't then it's virtually impossible for GNU to switch code bases (not that it would have been likely anyway).

Re: Continued progress porting Emacs to Rust

#18

Post by tsmarsh »

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

Yeah, it does that. Its not just emacs lisp, clojure, clojurescript and CL2 all have tight integration.

The difference is what it means for your repl. You can trivially attach your repl to a running process. So you change an expression, tell emacs that you'd like that to be sent to the repl, and because the repl is attached to your running process everything updates immediately.

I put this together years ago: https://www.youtube.com/watch?v=W2NJppeLsN8

It does a pretty terrible job of demonstrating what this might mean for something like web development where the feedback circle is usually as bad as it can be.

Re: Continued progress porting Emacs to Rust

#19

Post by ams6110 »

Emacs rather famously has a build process that involves first compiling a minimal elisp environment (written in C and maybe some assembly) that then loads all the editing routines (which are written in elisp) and then dumps itself out as a binary (to save the load time, which is substantial, on subsequent start-ups).

I assume the Rust-based emacs would do the same thing?

Re: Continued progress porting Emacs to Rust

#20

Post by tom_mellior »

The author misunderstands some parts of the C language, in particular related to static variables. "In fact, these aren't just file globals accessible to only one translation unit, these are static variables that are accessible across the whole program." gets the meaning of C's static exactly backwards: C file-scope static variables are only accessible (by name) in their translation unit; all other file-scope variables are extern by default.

More importantly, they write:

    static struct Lisp_Objfwd o_fwd;
"... creates an (uninitialized) static variable called o_fwd". No. C static variables are implicitly initialized to zero of the appropriate type, in this case, apparently a struct containing only a null pointer. This also means that their

        unsafe {
            #[allow(const_err)]
            static mut o_fwd: ::hacks::Hack =
                unsafe { ::hacks::Hack::uninitialized() };
"a lot more typing to get a proper uninitialized value in a Rust program" is just useless voodoo.
Post reply on HN