diff options
Diffstat (limited to '2024/talks/gypsum.md')
| -rw-r--r-- | 2024/talks/gypsum.md | 62 |
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"]] |