add answers captionsHEADmaster

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.