gypsum

1 files changed, 62 insertions, 0 deletions

diff --git a/2024/talks/gypsum.md b/2024/talks/gypsum.md
index f1d6aecd..a76afb02 100644
--- a/2024/talks/gypsum.md
+++ b/2024/talks/gypsum.md
@@ -362,6 +362,68 @@ professionally.
 You may also like another talk by this speaker:
 [EmacsConf - 2022 - talks - Build a Zettelkasten with the Hyperbole Rolodex](https://emacsconf.org/2022/talks/rolodex/)
 
+# Discussion
+
+## Questions and answers
+
+-   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 that 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. 
+        -   thank you
+
+- 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.
+-   Q: \<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 namespace stuff?
+
+## Notes
+
+-   \<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
+-   \<tusharhero\> Q: Not really a question, but how about Schemacs as a
+    name?
+-   \<janneke\> robin: yes, guile-elisp not being portable might be a
+    showstopper
+-                       for ramin
+
+
 [[!inline pages="internal(2024/info/gypsum-after)" raw="yes"]]
 
 [[!inline pages="internal(2024/info/gypsum-nav)" raw="yes"]]