diff options
author | Sacha Chua <sacha@sachachua.com> | 2024-12-13 11:03:03 -0500 |
---|---|---|
committer | Sacha Chua <sacha@sachachua.com> | 2024-12-13 11:03:03 -0500 |
commit | 1147abeaa0686a5ae3c71df674ccd709b4b3617f (patch) | |
tree | 3254abd08a949d665ed0d2a1fa853cf917241f89 /2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt | |
parent | d99364ed2b2d51acdf668525d5b449a25d8a37c0 (diff) | |
download | emacsconf-wiki-master.tar.xz emacsconf-wiki-master.zip |
Diffstat (limited to '2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt')
-rw-r--r-- | 2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt | 725 |
1 files changed, 725 insertions, 0 deletions
diff --git a/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt b/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt new file mode 100644 index 00000000..0142a879 --- /dev/null +++ b/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt @@ -0,0 +1,725 @@ +WEBVTT + +00:00.069 --> 00:01.850 +Troy Hinckley's project that I'm talking about. I was going + +00:02.350 --> 00:22.139 +to mention this in my presentation, but it's possible, + +00:02.350 --> 00:22.139 +theoretically, that Troy Hinckley, his project could be + +00:02.350 --> 00:22.139 +used as a scheme of limitation that actually runs my own + +00:02.350 --> 00:22.139 +version of Emacs. And although, you know, This is + +00:25.478 --> 00:29.380 +completely theoretical, and I don't know how difficult + +00:25.478 --> 00:29.380 +that would be. But if Troy Hinckley implemented enough of + +00:30.781 --> 00:47.029 +the R7-RS standard in Rust, it would theoretically be + +00:30.781 --> 00:47.029 +possible to run the Gypsum editor in Troy Hinckley's own + +00:30.781 --> 00:47.029 +editor. I thought that was kind of interesting, and I + +00:48.270 --> 00:53.833 +thought it was worth mentioning, at least in the questions + +00:48.270 --> 00:53.833 +and answers. + +01:12.179 --> 01:14.080 +I also mentioned this in the presentation. I wanted to see + +01:14.940 --> 01:22.364 +Robin Templeton's project presentation, but + +01:14.940 --> 01:22.364 +unfortunately it's going to be at like four in the morning + +01:14.940 --> 01:22.364 +for me. So I'm going to try and watch that tomorrow, but + +01:22.984 --> 01:31.428 +that's also going to be a very interesting project to keep an + +01:22.984 --> 01:31.428 +eye on if you're interested in Scheme. That's the project + +01:33.149 --> 01:38.051 +where you've got the Guylain interpreter running inside of + +01:33.149 --> 01:38.051 +the Emacs process. It's dynamically linked as a library. + +02:04.699 --> 02:06.748 +I'm ready for questions from anybody. You can ask or you can + +02:07.431 --> 02:09.079 +type. It's up to you. + +02:32.319 --> 02:34.521 +Okay, let me check the etherpad. + +02:37.304 --> 02:38.245 +Let's see here. + +02:41.208 --> 02:42.830 +I'm not sure if I'm doing that right. + +02:46.373 --> 02:47.554 +Let me check one more time. Oh, there it goes. + +02:54.221 --> 02:55.702 +Let's see, so this is... + +03:00.151 --> 03:02.072 +I didn't know about that first bit of history. Oh, I've heard + +03:02.332 --> 00:03:09.369 +RMS say that Scheme Guile is just a nicer Lisp, but I didn't + +03:02.332 --> 03:09.776 +know there were concrete talks attempts to use Guile for + +03:02.332 --> 03:09.776 +Emacs that early. Let's see, that was from janneke. + +NOTE 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? + +00:03:09.370 --> 00:03:19.241 +I'm curious to know how the hell Guile Emacs deals with all the + +03:14.318 --> 03:19.241 +dynamically scoped modules out there. Is there any effort + +03:20.181 --> 03:24.943 +to automatically modularize and name? Let's see. + +03:30.523 --> 03:35.806 +That might be a better question for Robin Templeton. In my + +03:36.727 --> 03:46.573 +own project, + +03:36.727 --> 03:46.573 +there's no module system for Emacs Lisp. There is a module + +03:46.693 --> 03:48.234 +system for Scheme. And the Emacs Lisp interpreter runs in + +03:49.695 --> 03:55.158 +its own environment. the require system or whatever module + +03:57.068 --> 04:11.736 +system that Emacs has, once it's implemented, all of that + +03:57.068 --> 04:11.736 +would just happen inside of the Emacs Lisp environment, + +03:57.068 --> 04:11.736 +which is inside of the Scheme environment. And + +04:12.437 --> 04:15.898 +environments are objects in Scheme. + +04:21.522 --> 04:24.103 +I think a more difficult question is how to handle + +04:26.420 --> 04:31.942 +threading, and Scheme has very good threading built in, in + +04:26.420 --> 04:31.942 +Serphe-18[??]. + +04:34.283 --> 04:48.028 +But I don't think it will be easy to write Emacs Lisp form + +04:34.283 --> 04:48.028 +bindings to the Scheme multi-threading implementation. + +04:48.548 --> 04:50.749 +Emacs Lisp was just not cut out for that kind of thing. So I + +04:51.710 --> 04:59.894 +think each Emacs Lisp, you could, I suppose, have multiple + +04:51.710 --> 04:59.894 +threads each running their own Emacs Lisp environment. + +05:01.375 --> 05:02.956 +Scheme would make that very simple to do. + +05:06.018 --> 05:16.744 +And then there'd just be a question of how you would get those + +05:06.018 --> 05:16.744 +different interpreters to communicate with each other, + +05:06.018 --> 05:16.744 +perhaps using the same protocol that's used by the Emacs + +05:06.018 --> 05:16.744 +server. But I haven't thought that far ahead yet. + +NOTE Q: Would it be possible to support a GUI toolkit other than GTK? + +05:23.646 --> 05:28.709 +Would it be possible to support a GUI toolkit other than the + +05:23.646 --> 05:28.709 +GTK? Like, how is it still supports Lucid? Yes, this is + +05:31.291 --> 05:33.232 +absolutely a goal of the project. I'm trying to keep the back + +05:33.873 --> 05:38.416 +end separate as possible. The scheme has what you call + +05:39.817 --> 05:42.478 +parameters. And these are like global variables that are + +05:43.199 --> 05:46.221 +still somewhat thread safe. And every call to the GUI goes + +05:47.484 --> 05:51.225 +through a parameter. So the Emacs, the interpreter and the + +05:52.125 --> 05:59.367 +editor logic is all in one module. And then that module calls + +05:59.987 --> 06:04.309 +out into a separate GUI module. And then you can implement + +06:04.989 --> 06:07.690 +different GUI modules. So you could have one for GTK3, one + +06:08.430 --> 06:13.171 +for GTK4, if you want to write the extern C bindings around Qt + +06:13.843 --> 06:20.725 +or full tick, that would certainly be possible as well. It + +06:21.185 --> 06:32.168 +would be nice maybe to have an SDL implementation based + +06:21.185 --> 06:32.168 +maybe on Chikiti or some kind of immediate mode GUI, + +06:21.185 --> 06:32.168 +something like that. But definitely GTK3 through Guile GI + +06:33.808 --> 06:38.750 +is the reference implementation. Things start there. But + +06:41.298 --> 06:43.959 +I'm very interested in supporting other GUIs, yes. Let's + +06:45.199 --> 00:06:45.256 +see. + +NOTE 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? + +00:06:45.257 --> 00:06:45.879 +Question, do you plan to provide improvements to ELisp + +06:47.540 --> 06:56.342 +as a language or focus on a compatibility layer to + +06:47.540 --> 06:56.342 +facilitate all new extensions in Scheme? Yeah, the second + +06:57.142 --> 06:57.962 +one. I want to move off to Scheme. I would like for this + +07:03.384 --> 07:05.264 +project to try and keep up to date with each new release of + +07:05.666 --> 07:10.789 +Emacs and Emacs Lisp. That's a difficult moving target to + +07:11.850 --> 07:14.552 +follow, I realize. But to the greatest extent possible, any + +07:15.152 --> 07:23.397 +new features to Emacs Lisp will be pulled in from GNU Emacs. + +07:25.419 --> 07:29.041 +If we happen to be able to implement something cool in + +07:25.419 --> 07:29.041 +Scheme, and be able to port it over to Emacs Lisp, then sure, + +07:29.437 --> 07:36.543 +it'd be nice to be able to upload or to submit that upstream to + +07:29.437 --> 07:36.543 +the GNU Emacs. But I think I would prefer to have new features + +07:38.584 --> 07:43.708 +written in Scheme. I would like this gypsum to be more of a + +07:43.989 --> 07:52.075 +Scheme app platform that just happens to be able to also run + +07:43.989 --> 07:52.075 +Emacs Lisp. That's how I see it. Of course, this will be a + +07:54.577 --> 07:56.699 +community project. I'm open to debate about that if anybody + +07:58.809 --> 08:02.012 +wants to convince me otherwise. + +08:08.439 --> 08:11.683 +Why is being able to interpret all of that EL a useful goal? + +08:12.464 --> 08:14.626 +Sure, there is a lot of code written in Elisp. Can we + +08:15.206 --> 08:17.749 +consider... Oh, it's still being written. Please go ahead + +08:18.390 --> 08:19.491 +and finish writing. + +NOTE Q: Can we consider a translator like utility to convert elisp to scheme, once guile-emacs becomes a reality? + +08:29.673 --> 08:35.576 +Can we consider a translator like utility to convert eLisp + +08:29.673 --> 08:35.576 +to Scheme once Guile-Emacs has become a reality? + +08:36.716 --> 08:37.076 +Certainly. For the time being, I just wanted to get the + +08:38.717 --> 08:42.639 +interpreter running. So the actual, the Guile-Emacs Lisp, + +08:44.520 --> 08:58.666 +the one that was written in 2011 that I didn't write, that + +08:44.520 --> 08:58.666 +actually does compile to, I think it's the tree + +08:44.520 --> 08:58.666 +intermediate representation It's one of the intermediate + +08:59.076 --> 09:03.697 +languages that Guile uses to compile Guile scheme itself. + +09:04.817 --> 09:09.299 +So the Emacs lisp that was written before actually does + +09:04.817 --> 09:09.299 +that. It actually compiles and makes use of the entire Guile + +09:09.339 --> 09:20.761 +compiler tool chain and actually produces like JIT + +09:09.339 --> 09:20.761 +compilable binaries, which is really cool. Like I said, + +09:23.342 --> 09:25.943 +that's the one that I had trouble getting to work properly. + +09:29.209 --> 09:30.890 +Maybe we can follow that architecture. I'm not sure how to do + +09:33.052 --> 09:45.102 +that, but I would like to be able to do some kind of + +09:33.052 --> 09:45.102 +translating, keeping in mind that we want to have this be + +09:33.052 --> 09:45.102 +portable, do various schemes. And so Guile makes this very + +09:45.988 --> 09:50.289 +easy, but other schemes don't. Gambit might do this pretty + +09:51.549 --> 09:53.530 +well as well. It compiles to C and then compiles C down to a + +09:53.950 --> 10:01.471 +dynamically linkable library. So yeah, I think probably + +10:03.372 --> 10:09.373 +the most portable, I'm just thinking out loud right now, + +10:10.652 --> 10:21.715 +most portable implementation will just be able to + +10:10.652 --> 10:21.715 +translate Emacs Lisp directly to Scheme, which is not what + +10:10.652 --> 10:21.715 +the old Guile Emacs Lisp implementation does. That goes to + +10:21.755 --> 10:26.777 +TreeIL, so it's very, very Guile-specific, can't be + +10:21.755 --> 10:26.777 +ported. But yeah, if we could somehow get Emacs Lisp + +10:28.359 --> 10:42.045 +translated to Scheme and then compiled, say, in Shea Scheme + +10:28.359 --> 10:42.045 +or Gambit or MIT Scheme or one of those other compilers, that + +10:28.359 --> 10:42.045 +would be very cool. And I would absolutely love to do that. + +10:44.906 --> 10:49.948 +And I would very quickly accept any code into the code base + +10:44.906 --> 10:49.948 +that would do that. + +NOTE Q: Why is being able to interpret all of \`init.el\` an useful goal? + +10:54.390 --> 10:56.291 +Oh, and to answer the question about init.el, + +10:59.207 --> 11:17.215 +It's just because people spend a lot of time on their configs + +10:59.207 --> 11:17.215 +and it would be nice if, you know, you're starting to use this + +10:59.207 --> 11:17.215 +new editor and want it to be similar to Emacs users, just the + +10:59.207 --> 11:17.215 +Emacs community in general and people who are familiar with + +10:59.207 --> 11:17.215 +using Emacs. It would be more useful to everybody in the + +11:17.715 --> 11:25.379 +Emacs community if this were more compatible with GNU + +11:17.715 --> 11:25.379 +Emacs. And so that's why that's, I think that's an important + +11:25.679 --> 11:27.960 +goal. + +11:34.465 --> 11:35.467 +Question is not yet. Great. Oh, here comes another + +11:38.471 --> 11:39.613 +question. + +NOTE Q: What is the plan to handle elisp packages that depend on 3rd party/external libraries? (libgit/magit or rg/ripgrep)? + +12:08.539 --> 12:17.742 +Okay, what is the plan to handle elisp packages that depend + +12:08.539 --> 12:17.742 +on third-party or external libraries like git or magit + +12:08.539 --> 12:17.742 +or ripgrep? So that's going to be tricky. It depends on how + +12:21.523 --> 12:26.224 +these external packages are linked into emacs. If it's + +12:26.844 --> 12:33.646 +going to be a dynamic library like Robin Templeton's + +12:26.844 --> 12:33.646 +project which you load the libgit library into the Emacs + +12:35.289 --> 12:41.931 +process, that is going to be extremely difficult. So if you + +12:44.032 --> 12:52.975 +have an external library like, I don't know, libgit or + +12:44.032 --> 12:52.975 +what's the GUI thing? Cabal. No, not Cabal. Cairo, libcairo + +12:57.736 --> 13:01.398 +to do SVG graphics and so on. + +13:04.483 --> 13:17.480 +You can do that very easily with Guile, but then on top of + +13:04.483 --> 13:17.480 +that, implementing Emacs list bindings to it, I mean, + +13:04.483 --> 13:17.480 +you've got two layers there, and that makes things pretty + +13:04.483 --> 13:17.480 +difficult. So it's possible. And to some degree, maybe + +13:21.935 --> 13:30.842 +necessary for example, Cairo, if we want to do SVG graphics + +13:21.935 --> 13:30.842 +the way that Emacs Lisp does, we're going to have to have + +13:21.935 --> 13:30.842 +that. So that would be necessary. We would have to have those + +13:32.643 --> 13:33.944 +two layers. Yes, let's do that. But if it's like for Magit, + +13:38.047 --> 13:50.596 +you can just call out to your git process, and then you're + +13:38.047 --> 13:50.596 +just using the regular process APIs that Emacs Lisp has. And + +13:51.451 --> 13:58.475 +that can be, already we, like Guile has some very good + +13:51.451 --> 13:58.475 +implementations for process management. And so it would + +13:59.055 --> 14:05.438 +just be a matter of wrapping up those in the Emacs lisp form + +13:59.055 --> 14:05.438 +bindings. So yeah, dynamic libraries, I wanna try to avoid. + +14:12.222 --> 14:20.366 +And I would prefer to do things more through, you know, + +14:12.222 --> 14:20.366 +launching a child process in the Emacs process. and then + +14:20.956 --> 14:24.798 +communicating over the standard in, standard out + +14:20.956 --> 14:24.798 +channels. + +14:29.460 --> 14:40.386 +That's the easier way to do things, I think, because then you + +14:29.460 --> 14:40.386 +can just use the process library that Emacs already has, and + +14:29.460 --> 14:40.386 +you can just reuse all of that code. + +14:43.969 --> 14:49.912 +I'm not sure how ripgrep works, unfortunately, but I + +14:43.969 --> 14:49.912 +believe that's also a process, a child process. So, we can + +14:50.412 --> 14:53.774 +just reuse all of the Emacs Lisp code that does that already. + +14:54.014 --> 15:05.979 +We just need to make sure that the process management + +14:54.014 --> 15:05.979 +implementation and scheme is properly bound to Emacs Lisp, + +14:54.014 --> 15:05.979 +and it works the same as GNU Emacs does. Once that's all set, + +15:06.360 --> 15:13.383 +then these porcelains, like around git, should fall into + +15:06.360 --> 15:13.383 +place. without too much difficulty, hopefully. + +NOTE Q: Not really a question, but how about Schemacs as a name? + +15:21.112 --> 15:22.593 +How about Schemax as a name? I like the name. I like that name. + +15:28.937 --> 15:32.920 +I haven't really looked into like, is that already used or is + +15:28.937 --> 15:32.920 +that going to be confusing? But certainly something we can + +15:33.380 --> 15:35.021 +discuss. + +15:38.243 --> 15:39.264 +Another thing I should mention, + +15:42.157 --> 15:48.278 +I should probably set up a server or something like Discord + +15:42.157 --> 15:48.278 +or something like that. Discourse, not Discord. + +15:51.619 --> 15:56.220 +Discourse, the open source one, where we could actually + +15:51.619 --> 15:56.220 +chat about this stuff. For the time being, ActivityPub, + +15:56.540 --> 16:05.562 +mostly Mastodon, is how I communicate with people in real + +15:56.540 --> 16:05.562 +time, that or email. So if you want to get a hold of me, check + +16:09.809 --> 16:15.571 +the notes for this presentation and just send me an email. + +16:16.752 --> 16:18.012 +Any question at all is fine. If you want to contribute code, + +16:19.633 --> 16:25.495 +if you want to just learn how to contribute code, send me any + +16:19.633 --> 16:25.495 +questions. It's fine. I'm happy to answer them. And we can + +16:30.256 --> 16:31.757 +talk about the name as well. + +NOTE 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? + +16:45.931 --> 16:54.215 +Okay, why is it not feasible for the Emacs layer that + +16:45.931 --> 16:54.215 +interprets Emacs Lisp, the core in C, have a Scheme + +16:45.931 --> 16:54.215 +interpreter instead of using Guile? Let's see, I have to, + +16:55.496 --> 16:57.257 +okay. Emacs layer interprets Emacs Lisp, the core in C, have + +16:57.737 --> 17:05.942 +a Scheme interpreter instead of using Guile. Okay, so that, + +17:07.362 --> 17:13.906 +the question xlarsx is asking, xlars, x, So Lars is asking, + +17:14.744 --> 17:28.093 +is it not feasible for there to be an + +17:14.744 --> 17:28.093 +Emacs layer that interprets Emacs Lisp have a scheme + +17:14.744 --> 17:28.093 +interpreter? This is Robin Templeton's project. And + +17:30.815 --> 17:32.156 +they're presenting later today. So check the roster and be + +17:32.697 --> 17:41.303 +sure to see that presentation because that's exactly what + +17:32.697 --> 17:41.303 +Robin Templeton is doing. That's not what I'm doing though. + +17:44.419 --> 17:46.459 +I'm trying to create something in Scheme. But yes, there is + +17:48.280 --> 17:54.921 +an attempt to get an Scheme interpreter to run inside of + +17:48.280 --> 17:54.921 +Emacs itself. And it has its own method of binding to Emacs + +17:55.181 --> 18:05.323 +Lisp functions and translating data like Lisp structures + +17:55.181 --> 18:05.323 +between Guile Scheme and Emacs Lisp. Robin will explain all + +18:05.943 --> 18:08.284 +of that in their presentation. + +18:28.519 --> 18:33.020 +OK, I think I've got through all the questions on Etherpad. + +18:33.620 --> 18:35.500 +But I'm going to hang out here for a bit longer. And yeah, feel + +18:37.621 --> 18:46.182 +free to do a video chat with me or send me more questions on + +18:37.621 --> 18:46.182 +Etherpad or here in the big blue button. And so I'm just going + +18:47.002 --> 18:48.082 +to hang out. And thanks for asking all your questions. And + +18:51.663 --> 18:56.024 +yeah, I look forward to working with all of you if you're + +18:51.663 --> 18:56.024 +interested. take it easy. Thanks so much for the talk and + +18:59.935 --> 19:08.180 +looking forward to seeing some of your progress as this + +18:59.935 --> 19:08.180 +moves forward, exciting space. We'll go ahead and leave the + +19:09.261 --> 19:14.925 +room open for you and thanks for offering to hang out and chat + +19:09.261 --> 19:14.925 +with other people that come by. Feel free to throw something + +19:15.025 --> 19:18.287 +in the chat if you want to remind people you're still here. + +19:19.557 --> 19:25.143 +Meanwhile, on the stream, we have moved along to our next + +19:19.557 --> 19:25.143 +talk on Rust, and that is just getting started. But again, + +19:25.283 --> 19:30.549 +we're continuing to record this, and I'll just keep an eye on + +19:25.283 --> 19:30.549 +it to stop the recording. Thank you. Thank you. It was + +19:33.352 --> 19:33.853 +awesome. + +21:47.935 --> 21:50.558 +So it seems like it's slowed down here for the Q&A. I don't see + +21:50.638 --> 21:53.741 +anybody else on BBB, so I'm going to go ahead and stop the + +21:50.638 --> 21:53.741 +recording. We can start it back up. I would say, yes, there's + +21:55.282 --> 21:58.906 +a lot of things you can do with this. You can handle + +21:58.926 --> 22:00.627 +processing. Yeah, I'm going to try and join over the chat for + +22:02.029 --> 22:07.614 +the next talk. I'm not sure if I can do both big blue buttons at + +22:08.635 --> 22:11.538 +the same time. You should be able to just watch your mute + +22:13.206 --> 22:19.998 +settings and mute tab settings and whatever all you have to + +22:13.206 --> 22:19.998 +avoid bleed through. Okay. |