diff options
Diffstat (limited to '')
| -rw-r--r-- | 2024/talks/gypsum.md | 102 |
1 files changed, 100 insertions, 2 deletions
diff --git a/2024/talks/gypsum.md b/2024/talks/gypsum.md index 3ee5a75a..3ee7c4cd 100644 --- a/2024/talks/gypsum.md +++ b/2024/talks/gypsum.md @@ -9,8 +9,9 @@ # Gypsum: my clone of Emacs and ELisp written in Scheme Ramin Honary (he/him) + - Source code: <https://codeberg.org/ramin_hal9001/gypsum> - E-mail: <mailto:ramin.honary@gmail.com> - - ActivityPub: @ramin_hal9001@fe.disroot.org + - ActivityPub: [@ramin_hal9001@fe.disroot.org](https://fe.disroot.org/@ramin_hal9001) - Website: <https://tilde.town/~ramin_hal9001> [[!inline pages="internal(2024/info/gypsum-before)" raw="yes"]] @@ -284,7 +285,7 @@ Example program - Homepage :: <https://tilde.town/~ramin_hal9001> -- Codeberg :: <https://codeberg.org/ramin_hal9001> +- Codeberg :: <https://codeberg.org/ramin_hal9001/gypsum> - This presentation :: <https://emacsconf.org/2024/talks/gypsum/> @@ -361,6 +362,103 @@ 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: 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. + - IRC: Where do you think elisp documentation should be improved? I've always found the built in documentation to be excellent + - janneke is referring to Guile's ELisp support, I believe; sorry, i meant the documentation of guile's elisp backend +- 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: 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: 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: 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 + +- oo neat, i didn't know about that first bit of history +- 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 +- robin: yes, guile-elisp not being portable might be a + showstopper for ramin +- I've heard good things about guile from guix people. Never really tried it out +- FWIW, I think there have been various attempts to make an Emacs clone in Common Lisp. I guess lem is currently the most active. https://github.com/lem-project/lem/ +- I like how he edited his slide mid-presentation. +- https://www.emacswiki.org/emacs/GuileEmacsHistory has some info on very efforts; i was surprised that there were so many (especially with old-school guile, eww ;)) +- joining for all the guiles and all the emacsen +- He's got a long way to go. +- of course there were, RMS had decreed that guile was the GNU scripting language and it was a bit embarrassing that it was so little-used... + - At least Guix uses it now. + - oh yes, guile 3 was a great step forward, and I do wonder how much of that was due to the impetus of its having real users :) +- if you're interested in guile emacs, be sure to check out robin's guile talk this afternoon +- nice, my silly https://gitlab.com/janneke/guimax also used guile-gi but this looks much more mature +- developed actively til 2014, but more recent work is on a branch so may not be as obvious... +- so...i guess that some basic documentation on elisp may be very helpful +- wbn if you could join efforts somehow + - there should definitely be some overlap between the projects +- I have 6500 interactive ones, according to Vertico... + - I got 8021 interactive ones ;) + - 7690 here + - 34557 callables \o/ +- working towards a similar goal approached from different directions + - however, working on guile's elisp backend may be a common ground +- ramin's probably talking about subrs, i.e. primitives not themselves implemented in elisp +- you mean providing modularization for elisp programs? or something else +- Being more specific, removing the need to namespace every single internal variable/procedure in an elisp module. Maybe that isn't a goal, but I wish it were + - yes, i have some ideas for adapting the CL package system for that. it'd have to be opt-in, maybe some tools for automated refactoring +- And... the part where we need more bandwidth for any core runtime efforts to be viable +- my-special-module--loop-variable-3 +- How can I get involved with this? if I want to contribute + - hang out in #guile-emacs and/or subscribe to the mailing lists https://guile-emacs.org/ +- an embryonic re-implementation by ramin of emacs in guile, with their own new elisp interpreter that should be r7rs compatible +- would love robin's guile-emacs and ramin's efforts to somehow share some of their efforts +- Robin's talk mentions developing a better elisp in Scheme. Why can't your project leverage it? +- guile-elisp is part of guile's compiler system (elisp -> tree-il -> cps -> bytecode), unless another scheme sets out to be guile-compatible in that respect it won't be portable at all +- To be fair, I've been screwing around with chicken, guile, and racket. I haven't found any 2 scheme implementations to be compatible, even within SRFI implementations + - Just the basic syntax and semantics, nothing else + - yeah, scheme's lack of portable libraries in practice motivated me to suggest something that's sure to piss everyone off: Javascript +- YouTube comment: Cool, great, amazing. Extremely ambitious. A clone like this project might be significant harder than for example Lem, which does not care about backward compatibility with Emacs. A clone also is somewhat harder to create a unique selling point for. Especially if Guile-Emacs is also going to be a thing now. Just my 2 cents up to discussions. Anyway I am excited and will follow it:) + [[!inline pages="internal(2024/info/gypsum-after)" raw="yes"]] [[!inline pages="internal(2024/info/gypsum-nav)" raw="yes"]] |