All talks: https://emacsconf.org/2024/talks/
An experimental Emacs core in Rust
https://emacsconf.org/2024/talks/rust - Troy Hinckley - Track: Development
Watch/participate: https://emacsconf.org/2024/watch/dev/
Q&A room: https://media.emacsconf.org/2024/current/bbb-rust.html
IRC: https://chat.emacsconf.org/#/connect?join=emacsconf,emacsconf-dev or #emacsconf-dev on libera.chat network
Guidelines for conduct: https://emacsconf.org/conduct
See end of file for license (CC Attribution-ShareAlike 4.0 + GPLv3 or later)
----------------------------------------------------------------
Notes, discussions, links, feedback:

• <Psionic`> Getting good vibes from this Rust work
• <NullNix> (you can do the offscreen-cursor thing in current emacs with enough
•                     effort. see scroll-in-place.el.)
• <Psionic`> Oooooh flow images.  My last expectation was Rust making Dslide
•                      image animations slick
• <sctb> troyhinckley: Very cool talk! 
• <[> I recommend https://codeberg.org/ (as a freedom-respecting github
•         replacement)
• <NullNix> one big problem with using gtk -- there is a *two-decade-old* unfixed bug in gtk where it keeps permanent references to the x server etc (IIRC, its wayland support has similar problems). this means a gtk emacs --daemon crashes if you connect to an x server and then close the x server down. this is.... unfortunate

----------------------------------------------------------------
Questions and answers go here:

• Q: Have you considered using CRDTs to share buffers between threads and merge any concurrent edits automatically?
  • A: While mathematically correct, CRDT does not always produce a useful answer. With different packages, this will the issue: not a useful result. https://www.moment.dev/blog/lies-i-was-told-pt-1
• Q: Why hosted on GitHub? GitHub is nonfree. Is it possible to report bugs/send patches without using GitHub?
  • A: Email patches are possible. Github is what the speaker knows.
• Q: Do you think it's possible to achieve 100% compatibility with current emacs code? 
  • A: Most should be compatible (since elisp package is the biggest emacs strength) but there might be differences on purpose.
• Q: <janneke> troyhinckley: so you're re-implementing elisp in rust?  have you considered using a more modern lisp, such as scheme? [11:03]
  • A: No actually. Only trying to reimplementing the C part of emacs, replacing it by rust. There are two other talks in the conference to use something else (guile and scheme).
• Q:<lounge-681> can remacs be reused?
  • A: Some of the code and some of the ideas (documentation, ideas and approach to problems) were taken. But different model: in remacs everything is an external type. Here, instead trying, to use the builtin type reimplementating the objects instead.
• Q: <apiraino> hello, great talk, fascinating topic! I am a contributor of the compiler team of the Rust prog. language (though I don't delve in the code myself). Do you have specific features from the Rust compiler that are missing (or are nightly-only) that you would take advantage of?  10:05:38 
  • A: Polonius: the new borrow checker. Would solve lifetime-tracking issues. A better tracking mechanism would be better.
  • A: Enum with variant types to avoid boilerplate https://github.com/rust-lang/lang-team/issues/122
  • A: Allocator API could be better (still nightly-only)
  • A: <apiraino> thanks! Dont forget to fill out the survey :) https://blog.rust-lang.org/2024/12/05/annual-survey-2024-launch.html
• Q: What are you thoughts on the GUI layer. Any plans on how to reimplement it?
  • A: Either GTK+ or direct GUI in Rust, but no concrete plan so far.
• Q: <ramin> (not a question) Re. the GUI layer, the Gtk project has automated bindings with a framework called "GObject Introspection," which is what I am using for my "Gypsum" project. Probably Rust has a GObject Implementation which you could use.
  • A: Problem with Rust GUIs very new and mostly demo without accessibility and test in all environements.
• Q: If money could fix the problem, how much would it cost to ship this with feature parity before 2026?
  • A: Probably needs a couple people and more than one year of work. Lots of testing required to fix all bugs.
• Q: <janneke> troyhinckley: elisp is implemented in c, so if you're not implementing elisp in rust, are you using/keeping the c implementation of elisp?
  • A: Idea of the project is to keep the Elisp layer and changing the C layer underneath that is currently called, replacing it by rust. Elisp does not change. Plan is to be even be bug compatible to emacs: Elisp should be perfectly compatible with both C and rust. Elisp is fixed in this approach.
• Q: <ramin> sorry if you already discussed this, but will your Rust implementation also be able to run Emacs bytecode? Or are you implementing it at the Lisp level?
  • A: Bytecode interpreter already exists (actually bytecode compiler and interpreter was bootstrapped first as it is implemented in Elisp).
  • A: the bytecode is missing some OP-code that have not been encountered so far.
• Q: Cool, so will you also provide bytecode JIT compilation via "libgcc" the way Emacs currently does?
  • A: Eventually maybe, but a proper JIT would be better as it includes type information to better optimize the code.
•  Q: Is it possible to bootstrap without the interprerter?
  • A: having only bytecode does not work, as some part are expected to be interpreted with macros containing functions that are not yet defined. You really need an interpreter for the lazy macro expansion.
• Q: How would you do the native module system?  What would be different?  Sounded like part of an anwer about Rust Emacs modules got cut off.
  • A: There is an FFI, so it should be possible to have the same thing. Could possibley implement FFI in elisp.
• Q:  <ramin> That was me who was discussing with you about bootstrapping Scheme! (Not Guile, R7RS Scheme) Yes, it would be a whole other thing than what you have done so far. But it would be cool, because then you would be able to run the "Gypsum" editor on top of your Emacs engine.
  • A: <troyhinckley> I still think that would be really cool to get working! we will have to collaberate on that more.

----------------------------------------------------------------

Next talks:

• General: Colour your Emacs with ease https://pad.emacsconf.org/2024-color
• Development: p-search: a local search engine in Emacs https://pad.emacsconf.org/2024-p-search
• Development: Exploring shared philosophies in Julia and Emacs https://pad.emacsconf.org/2024-julia

Questions/comments related to EmacsConf 2024 as a whole? https://pad.emacsconf.org/2024
----------------------------------------------------------------
This pad will be archived at https://emacsconf.org/2024/talks/rust after the conference.
Except where otherwise noted, the material on the EmacsConf pad are dual-licensed under the terms of the Creative Commons Attribution-ShareAlike 4.0 International Public License; and the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) an later version. Copies of these two licenses are included in the EmacsConf wiki repository, in the COPYING.GPL and COPYING.CC-BY-SA files (https://emacsconf.org/COPYING/)
By contributing to this pad, you agree to make your contributions available under the above licenses. You are also promising that you are the author of your changes, or that you copied them from a work in the public domain or a work released under a free license that is compatible with the above two licenses. DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION.