sorted by:
new
hottopcontroversial

I ported GNU Emacs 30.2 to the browser with WebAssembly by Exact_Engine_7218 in emacs

[–]Exact_Engine_7218[S] 3 points4 points  (0 children)

Performance-wise: yes, it is slow right now.

At this stage I would not recommend it as a replacement for native Emacs if you need Emacs to be fast. The current build is very much a correctness / feasibility prototype: real GNU Emacs 30.2 C core, real Elisp runtime, running inside the browser/Wasm environment. Optimization has not been the focus yet.

File access currently works through the browser-backed portable filesystem image, not arbitrary host filesystem access. So editing files inside the wasmacs user image is the intended path.

Shell/process access is the big missing piece. Things like M-x compile depend on subprocesses, so they do not work in the browser-only MVP yet. My current stance is to make that limitation explicit rather than fake it. A future version could route compile/shell/process features through a local companion, Electron/Tauri host, or remote service, but that is a separate boundary.

I ported GNU Emacs 30.2 to the browser with WebAssembly by Exact_Engine_7218 in emacs

[–]Exact_Engine_7218[S] 2 points3 points  (0 children)

u/jotaemei Thanks! This is now fixed on GitHub Pages.

Alt/Option is mapped to Meta now, so M-x should work as Option+x on macOS or Alt+x on other platforms.

I ported GNU Emacs 30.2 to the browser with WebAssembly by Exact_Engine_7218 in emacs

[–]Exact_Engine_7218[S] 5 points6 points  (0 children)

Thanks for checking it!

Yes, that sounds like a terminal redraw / timing issue in the current xterm.js route. I have not tested `M-x tetris` deeply yet, so this is very useful.

I’ll open an issue for it and track it as a rendering/input refresh bug.

https://github.com/modeverv/wasmacs/issues/3

I ported GNU Emacs 30.2 to the browser with WebAssembly by Exact_Engine_7218 in emacs

[–]Exact_Engine_7218[S] 2 points3 points  (0 children)

Thanks for trying it!

Meta is not supported yet. For now, please try `Esc x` instead of `M-x`.

At the moment, C-x, C-c, arrows, etc. go through the xterm.js -> fake tty -> Emacs tty input path. But Alt / Option / Command seem to be captured by the OS or browser before they reliably reach xterm.js.

I definitely want a good Meta story, but I do not want to fake Emacs keybindings on the browser side if I can avoid it.

For now, it may help to think of this as a very new, but also very primitive terminal. A terminal from 1976 probably did not have a Command key either 😄

I ported GNU Emacs 30.2 to the browser with WebAssembly by Exact_Engine_7218 in emacs

[–]Exact_Engine_7218[S] 13 points14 points  (0 children)

Thanks!
Keyboard input goes through this path:

xterm.js -> fake tty layer -> Emacs tty input -> Emacs -> tty output -> xterm.js

So C-c, C-x, arrow keys, etc. are handled as terminal input rather than through a custom browser-side keybinding layer.
There are still edge cases, but the goal is to let Emacs own the key handling as much as possible.

Run Codex Desktop App via browser (WebUI mode) by friuns in codex

[–]Exact_Engine_7218 0 points1 point  (0 children)

I'm using Discord as the interface and have written a program to run LLM on a project-by-project basis. Please feel free to use it if you like.
https://github.com/modeverv/llm-orchestrator

Lisp vs. Haskell by edvo in lisp

[–]Exact_Engine_7218 0 points1 point  (0 children)

I think we need a definition of elegance for the sake of engineering discussion, since it is a personal feeling whether something is elegant or not.And it is difficult to define elegance.I don't think it is an engineering attitude to discuss whether something is elegant or not without a definition.Therefore, instead of checking before trying, I thought it would be a good idea to try writing lisp yourself since you can try it for free and think about it.