All talks: https://emacsconf.org/2024/talks/
Gypsum: my clone of Emacs and ELisp written in Scheme
https://emacsconf.org/2024/talks/gypsum - Ramin Honary - Track: Development
Watch/participate: https://emacsconf.org/2024/watch/dev/
Q&A room: https://media.emacsconf.org/2024/current/bbb-gypsum.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:
- <robin> oo neat, i didn't know about that first bit of history
- <janneke> i've heard rms say that scheme (guile) is just a nicer lisp; but didn't know there were concrete talks/attempts to use guile for emacs that early
- <gringo> I'm curious to know how the hell guile-emacs deals with all of the
- dynamically scoped modules out there. Is there any effort to
- automatically modularize and name
- <tusharhero> Q: Not really a question, but how about Schemacs as a name?space stuff?
- <janneke> robin: yes, guile-elisp not being portable might be a showstopper
- for ramin
----------------------------------------------------------------
Questions and answers go here:
- Q:Would it be possible to support a GUI toolkit other than GTK? Like how GNU Emacs still supports Lucid
- A: Yes this planed by having proper backend: emacs-lisp running into a module and the GUI being another module. So normalized communication. Currently GTK being standard implementation, also done here.
- Q: Do you plan to provide improvements to Elisp as a language, or is the focus on a compatibility layer to facilitate doing all new extensions, etc. in Scheme?
- A: Plan is to keep up-to-date with new releases. So new GNU feature should be included with each release. But also intend to have support for pure Scheme features.
- Q: <janneke> If Emacs Lisp support for Guile was documented better, could you be nudged/convinced to (re)start using, and contributing to that?
- A: Compatibility is the most important things. Documentation not sufficient to convince users to switch.
- Q: Why is being able to interpret all of `init.el` an useful goal? Sure, there is a lot of code written in elisp - can we consider a translator like utility to convert elisp to scheme, once guile-emacs becomes a reality?
- A: Probably, but first step is getting the interpretter working. Emacs-lisp basically compiled down to intermediate representation of the guile compiler [this was one of the hard things to get to work]. But unclear how this works for other schemes. Best solution probably translation elisp -> scheme, but this is not the approach that was done. Would be very cool to have. Feel free to give a PR.
- Q: What is the plan to handle elisp packages that depend on 3rd party/external libraries? (libgit/magit or rg/ripgrep)?
- A: Will be tricky. If loading directly into the elisp process, very hard. Cairo could help, but you need emacs lisp binding on top of that. For magit, you can call regular process communication via stdin/stdout; so you can reuse existing scheme libraries. Dynamic libraries not a goal. Rg/ripgrep probably the same with process communication.
- Q: <xlarsx`> Why is it not feasible for the Emacs layer taht interprets Emacs Lisp (the core in C) ot have a Scheme interpreter, instead of using Guile?
- A: <gringo> Guile is a scheme. Not sure what you mean.
- A: Check presentation later of Robin Templeton ("Beguiling Emacs: Guile-Emacs relaunched!"): the attempt exists by translating elisp to guile.
* Q: Not really a question, but how about Schemacs as a name?
- A: Cool name, but did not check if it is already used. Feel free to discuss by email.
----------------------------------------------------------------
Next talks:
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/gypsum 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.