-Troy Hinckley's project that I'm talking about. I was going +00:00:00.000 --> 00:00:02.999 +...Troy Hinckley's project that I'm talking about. I was going
+00:00:03.000 --> 00:00:08.799 to mention this in my presentation, but it's possible,
+00:00:08.800 --> 00:00:16.359 theoretically, that Troy Hinckley, his project could be
+00:00:16.360 --> 00:00:18.559 used as a scheme of limitation that actually runs my own
+00:00:18.560 --> 00:00:23.759 version of Emacs. And although, you know, This is
+00:00:23.760 --> 00:00:30.719 completely theoretical, and I don't know how difficult
+00:00:30.720 --> 00:00:34.079 that would be. But if Troy Hinckley implemented enough of
+00:00:34.080 --> 00:00:39.879 the R7-RS standard in Rust, it would theoretically be
+00:00:39.880 --> 00:00:46.719 possible to run the Gypsum editor in Troy Hinckley's own
+00:00:46.720 --> 00:00:50.239 editor. I thought that was kind of interesting, and I
+00:00:50.240 --> 00:00:59.119 thought it was worth mentioning, at least in the questions
+00:00:59.120 --> 00:01:12.159 and answers.
+00:01:12.160 --> 00:01:16.199 I also mentioned this in the presentation. I wanted to see
+00:01:16.200 --> 00:01:20.119 Robin Templeton's project presentation, but
+00:01:20.120 --> 00:01:22.399 unfortunately it's going to be at like four in the morning
+00:01:22.400 --> 00:01:26.239 for me. So I'm going to try and watch that tomorrow, but
+00:01:26.240 --> 00:01:29.559 that's also going to be a very interesting project to keep an
+00:01:29.560 --> 00:01:34.039 eye on if you're interested in Scheme. That's the project
+00:01:34.040 --> 00:01:37.519 where you've got the Guylain interpreter running inside of
+00:01:37.520 --> 00:02:04.679 the Emacs process. It's dynamically linked as a library.
+00:02:04.680 --> 00:02:08.759 I'm ready for questions from anybody. You can ask or you can
+00:02:08.760 --> 00:02:32.079 type. It's up to you.
+00:02:32.080 --> 00:02:37.319 Okay, let me check the etherpad.
+00:02:37.320 --> 00:02:41.159 Let's see here.
+00:02:41.160 --> 00:02:42.719 I'm not sure if I'm doing that right.
+00:02:42.720 --> 00:02:54.199 Let me check one more time. Oh, there it goes.
+00:02:54.200 --> 00:03:00.079 Let's see, so this is...
+00:03:00.080 --> 00:03:02.239 I didn't know about that first bit of history. Oh, I've heard
+00:03:02.240 --> 00:03:06.119 RMS say that Scheme Guile is just a nicer Lisp, but I didn't
+00:03:06.120 --> 00:03:09.079 know there were concrete talks attempts to use Guile for
+00:03:09.080 --> 00:03:14.319 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:14.320 --> 00:03:17.439 I'm curious to know how the hell Guile Emacs deals with all the
+00:03:17.440 --> 00:03:21.359 dynamically scoped modules out there. Is there any effort
+00:03:21.360 --> 00:03:29.759 to automatically modularize and name? Let's see.
+00:03:29.760 --> 00:03:40.919 That might be a better question for Robin Templeton. In my
+00:03:40.920 --> 00:03:44.639 own project,
+00:03:44.640 --> 00:03:49.399 there's no module system for Emacs Lisp. There is a module
+00:03:49.400 --> 00:03:55.559 system for Scheme. And the Emacs Lisp interpreter runs in
+00:03:55.560 --> 00:04:01.599 its own environment. the require system or whatever module
+00:04:01.600 --> 00:04:06.359 system that Emacs has, once it's implemented, all of that
+00:04:06.360 --> 00:04:09.759 would just happen inside of the Emacs Lisp environment,
+00:04:09.760 --> 00:04:12.399 which is inside of the Scheme environment. And
+00:04:12.400 --> 00:04:21.479 environments are objects in Scheme.
+00:04:21.480 --> 00:04:26.399 I think a more difficult question is how to handle
+00:04:26.400 --> 00:04:33.279 threading, and Scheme has very good threading built in, in
+00:04:33.280 --> 00:04:34.839 Serphe-18[??].
+00:04:34.840 --> 00:04:43.399 But I don't think it will be easy to write Emacs Lisp form
+00:04:43.400 --> 00:04:48.479 bindings to the Scheme multi-threading implementation.
+00:04:48.480 --> 00:04:52.279 Emacs Lisp was just not cut out for that kind of thing. So I
+00:04:52.280 --> 00:04:56.559 think each Emacs Lisp, you could, I suppose, have multiple
+00:04:56.560 --> 00:05:00.039 threads each running their own Emacs Lisp environment.
+00:05:00.040 --> 00:05:04.999 Scheme would make that very simple to do.
+00:05:05.000 --> 00:05:08.759 And then there'd just be a question of how you would get those
+00:05:08.760 --> 00:05:11.679 different interpreters to communicate with each other,
+00:05:11.680 --> 00:05:16.279 perhaps using the same protocol that's used by the Emacs
+00:05:16.280 --> 00:05:23.639 server. But I haven't thought that far ahead yet. NOTE Q: Would it be possible to support a GUI toolkit other than GTK?
+00:05:23.640 --> 00:05:26.839 Would it be possible to support a GUI toolkit other than the
+00:05:26.840 --> 00:05:31.319 GTK? Like, how is it still supports Lucid? Yes, this is
+00:05:31.320 --> 00:05:36.999 absolutely a goal of the project. I'm trying to keep the back
+00:05:37.000 --> 00:05:41.599 end separate as possible. The scheme has what you call
+00:05:41.600 --> 00:05:45.239 parameters. And these are like global variables that are
+00:05:45.240 --> 00:05:50.519 still somewhat thread safe. And every call to the GUI goes
+00:05:50.520 --> 00:05:58.199 through a parameter. So the Emacs, the interpreter and the
+00:05:58.200 --> 00:06:01.679 editor logic is all in one module. And then that module calls
+00:06:01.680 --> 00:06:06.319 out into a separate GUI module. And then you can implement
+00:06:06.320 --> 00:06:11.599 different GUI modules. So you could have one for GTK3, one
+00:06:11.600 --> 00:06:16.879 for GTK4, if you want to write the extern C bindings around Qt
+00:06:16.880 --> 00:06:21.199 or full tick, that would certainly be possible as well. It
+00:06:21.200 --> 00:06:25.919 would be nice maybe to have an SDL implementation based
+00:06:25.920 --> 00:06:30.999 maybe on Chikiti or some kind of immediate mode GUI,
+00:06:31.000 --> 00:06:37.399 something like that. But definitely GTK3 through Guile GI
+00:06:37.400 --> 00:06:41.319 is the reference implementation. Things start there. But
+00:06:41.320 --> 00:06:43.999 I'm very interested in supporting other GUIs, yes. Let's
+00:06:44.000 --> 00:06:46.039 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:46.040 --> 00:06:50.759 Question, do you plan to provide improvements to ELisp
+00:06:50.760 --> 00:06:54.519 as a language or focus on a compatibility layer to
+00:06:54.520 --> 00:06:57.999 facilitate all new extensions in Scheme? Yeah, the second
+00:06:58.000 --> 00:07:04.719 one. I want to move off to Scheme. I would like for this
+00:07:04.720 --> 00:07:08.999 project to try and keep up to date with each new release of
+00:07:09.000 --> 00:07:13.799 Emacs and Emacs Lisp. That's a difficult moving target to
+00:07:13.800 --> 00:07:18.639 follow, I realize. But to the greatest extent possible, any
+00:07:18.640 --> 00:07:25.239 new features to Emacs Lisp will be pulled in from GNU Emacs.
+00:07:25.240 --> 00:07:28.599 If we happen to be able to implement something cool in
+00:07:28.600 --> 00:07:31.639 Scheme, and be able to port it over to Emacs Lisp, then sure,
+00:07:31.640 --> 00:07:35.799 it'd be nice to be able to upload or to submit that upstream to
+00:07:35.800 --> 00:07:43.079 the GNU Emacs. But I think I would prefer to have new features
+00:07:43.080 --> 00:07:47.799 written in Scheme. I would like this gypsum to be more of a
+00:07:47.800 --> 00:07:51.479 Scheme app platform that just happens to be able to also run
+00:07:51.480 --> 00:07:56.199 Emacs Lisp. That's how I see it. Of course, this will be a
+00:07:56.200 --> 00:08:00.799 community project. I'm open to debate about that if anybody
+00:08:00.800 --> 00:08:02.079 wants to convince me otherwise.
+00:08:02.080 --> 00:08:11.759 Why is being able to interpret all of that EL a useful goal?
+00:08:11.760 --> 00:08:15.519 Sure, there is a lot of code written in Elisp. Can we
+00:08:15.520 --> 00:08:18.959 consider... Oh, it's still being written. Please go ahead
+00:08:18.960 --> 00:08:19.439 and finish writing. NOTE Q: Can we consider a translator like utility to convert elisp to scheme, once guile-emacs becomes a reality?
+00:08:19.440 --> 00:08:32.519 Can we consider a translator like utility to convert eLisp
+00:08:32.520 --> 00:08:37.519 to Scheme once Guile-Emacs has become a reality?
+00:08:37.520 --> 00:08:42.119 Certainly. For the time being, I just wanted to get the
+00:08:42.120 --> 00:08:47.559 interpreter running. So the actual, the Guile-Emacs Lisp,
+00:08:47.560 --> 00:08:51.919 the one that was written in 2011 that I didn't write, that
+00:08:51.920 --> 00:08:57.599 actually does compile to, I think it's the tree
+00:08:57.600 --> 00:08:59.239 intermediate representation It's one of the intermediate
+00:08:59.240 --> 00:09:03.759 languages that Guile uses to compile Guile scheme itself.
+00:09:03.760 --> 00:09:09.079 So the Emacs lisp that was written before actually does
+00:09:09.080 --> 00:09:13.119 that. It actually compiles and makes use of the entire Guile
+00:09:13.120 --> 00:09:17.479 compiler tool chain and actually produces like JIT
+00:09:17.480 --> 00:09:21.719 compilable binaries, which is really cool. Like I said,
+00:09:21.720 --> 00:09:27.519 that's the one that I had trouble getting to work properly.
+00:09:27.520 --> 00:09:34.399 Maybe we can follow that architecture. I'm not sure how to do
+00:09:34.400 --> 00:09:37.919 that, but I would like to be able to do some kind of
+00:09:37.920 --> 00:09:41.999 translating, keeping in mind that we want to have this be
+00:09:42.000 --> 00:09:48.919 portable, do various schemes. And so Guile makes this very
+00:09:48.920 --> 00:09:52.719 easy, but other schemes don't. Gambit might do this pretty
+00:09:52.720 --> 00:09:57.919 well as well. It compiles to C and then compiles C down to a
+00:09:57.920 --> 00:10:06.159 dynamically linkable library. So yeah, I think probably
+00:10:06.160 --> 00:10:09.559 the most portable, I'm just thinking out loud right now,
+00:10:09.560 --> 00:10:13.239 most portable implementation will just be able to
+00:10:13.240 --> 00:10:17.119 translate Emacs Lisp directly to Scheme, which is not what
+00:10:17.120 --> 00:10:22.439 the old Guile Emacs Lisp implementation does. That goes to
+00:10:22.440 --> 00:10:26.439 TreeIL, so it's very, very Guile-specific, can't be
+00:10:26.440 --> 00:10:30.799 ported. But yeah, if we could somehow get Emacs Lisp
+00:10:30.800 --> 00:10:36.999 translated to Scheme and then compiled, say, in Shea Scheme
+00:10:37.000 --> 00:10:40.879 or Gambit or MIT Scheme or one of those other compilers, that
+00:10:40.880 --> 00:10:44.919 would be very cool. And I would absolutely love to do that.
+00:10:44.920 --> 00:10:49.279 And I would very quickly accept any code into the code base
+00:10:49.280 --> 00:10:50.599 that would do that. NOTE Q: Why is being able to interpret all of \`init.el\` an useful goal?
+00:10:50.600 --> 00:10:59.119 Oh, and to answer the question about init.el,
+00:10:59.120 --> 00:11:02.839 It's just because people spend a lot of time on their configs
+00:11:02.840 --> 00:11:06.959 and it would be nice if, you know, you're starting to use this
+00:11:06.960 --> 00:11:14.079 new editor and want it to be similar to Emacs users, just the
+00:11:14.080 --> 00:11:16.519 Emacs community in general and people who are familiar with
+00:11:16.520 --> 00:11:20.879 using Emacs. It would be more useful to everybody in the
+00:11:20.880 --> 00:11:25.119 Emacs community if this were more compatible with GNU
+00:11:25.120 --> 00:11:35.999 Emacs. And so that's why that's, I think that's an important
+00:11:36.000 --> 00:11:38.559 goal.
+00:11:38.560 --> 00:12:01.839 Question is not yet. Great. Oh, here comes another
+00:12:01.840 --> 00:12:02.279 question. NOTE Q: What is the plan to handle elisp packages that depend on 3rd party/external libraries? (libgit/magit or rg/ripgrep)?
+00:12:02.280 --> 00:12:11.879 Okay, what is the plan to handle elisp packages that depend
+00:12:11.880 --> 00:12:16.119 on third-party or external libraries like git or magit
+00:12:16.120 --> 00:12:22.719 or ripgrep? So that's going to be tricky. It depends on how
+00:12:22.720 --> 00:12:27.079 these external packages are linked into emacs. If it's
+00:12:27.080 --> 00:12:32.879 going to be a dynamic library like Robin Templeton's
+00:12:32.880 --> 00:12:38.039 project which you load the libgit library into the Emacs
+00:12:38.040 --> 00:12:43.159 process, that is going to be extremely difficult. So if you
+00:12:43.160 --> 00:12:49.359 have an external library like, I don't know, libgit or
+00:12:49.360 --> 00:12:59.279 what's the GUI thing? Cabal. No, not Cabal. Cairo, libcairo
+00:12:59.280 --> 00:13:01.439 to do SVG graphics and so on.
+00:13:01.440 --> 00:13:09.719 You can do that very easily with Guile, but then on top of
+00:13:09.720 --> 00:13:14.719 that, implementing Emacs list bindings to it, I mean,
+00:13:14.720 --> 00:13:17.199 you've got two layers there, and that makes things pretty
+00:13:17.200 --> 00:13:23.119 difficult. So it's possible. And to some degree, maybe
+00:13:23.120 --> 00:13:27.799 necessary for example, Cairo, if we want to do SVG graphics
+00:13:27.800 --> 00:13:30.599 the way that Emacs Lisp does, we're going to have to have
+00:13:30.600 --> 00:13:33.959 that. So that would be necessary. We would have to have those
+00:13:33.960 --> 00:13:39.199 two layers. Yes, let's do that. But if it's like for Magit,
+00:13:39.200 --> 00:13:45.479 you can just call out to your git process, and then you're
+00:13:45.480 --> 00:13:50.719 just using the regular process APIs that Emacs Lisp has. And
+00:13:50.720 --> 00:13:57.119 that can be, already we, like Guile has some very good
+00:13:57.120 --> 00:14:08.079 implementations for process management. And so it would
+00:14:08.080 --> 00:14:12.439 just be a matter of wrapping up those in the Emacs lisp form
+00:14:12.440 --> 00:14:24.919 bindings. So yeah, dynamic libraries, I wanna try to avoid.
+00:14:24.920 --> 00:14:32.799 And I would prefer to do things more through, you know,
+00:14:32.800 --> 00:14:40.399 launching a child process in the Emacs process. and then
+00:14:40.400 --> 00:14:47.239 communicating over the standard in, standard out
+00:14:47.240 --> 00:14:47.959 channels.
+00:14:47.960 --> 00:14:52.799 That's the easier way to do things, I think, because then you
+00:14:52.800 --> 00:14:58.519 can just use the process library that Emacs already has, and
+00:14:58.520 --> 00:15:03.239 you can just reuse all of that code.
+00:15:03.240 --> 00:15:09.079 I'm not sure how ripgrep works, unfortunately, but I
+00:15:09.080 --> 00:15:15.279 believe that's also a process, a child process. So, we can
+00:15:15.280 --> 00:15:23.479 just reuse all of the Emacs Lisp code that does that already.
+00:15:23.480 --> 00:15:30.399 We just need to make sure that the process management
+00:15:30.400 --> 00:15:35.119 implementation and scheme is properly bound to Emacs Lisp,
+00:15:35.120 --> 00:15:43.359 and it works the same as GNU Emacs does. Once that's all set,
+00:15:43.360 --> 00:15:48.399 then these porcelains, like around git, should fall into
+00:15:48.400 --> 00:15:55.279 place. without too much difficulty, hopefully. NOTE Q: Not really a question, but how about Schemacs as a name?
+00:15:55.280 --> 00:15:59.199 How about Schemax as a name? I like the name. I like that name.
+00:15:59.200 --> 00:16:03.119 I haven't really looked into like, is that already used or is
+00:16:03.120 --> 00:16:09.759 that going to be confusing? But certainly something we can
+00:16:09.760 --> 00:16:10.959 discuss.
+00:16:10.960 --> 00:16:13.039 Another thing I should mention,
+00:16:13.040 --> 00:16:18.759 I should probably set up a server or something like Discord
+00:16:18.760 --> 00:16:25.359 or something like that. Discourse, not Discord.
+00:16:25.360 --> 00:16:31.599 Discourse, the open source one, where we could actually
+00:16:31.600 --> 00:16:49.239 chat about this stuff. For the time being, ActivityPub,
+00:16:49.240 --> 00:16:52.399 mostly Mastodon, is how I communicate with people in real
+00:16:52.400 --> 00:16:57.279 time, that or email. So if you want to get a hold of me, check
+00:16:57.280 --> 00:17:02.439 the notes for this presentation and just send me an email.
+00:17:02.440 --> 00:17:09.039 Any question at all is fine. If you want to contribute code,
+00:17:09.040 --> 00:17:12.799 if you want to just learn how to contribute code, send me any
+00:17:12.800 --> 00:17:22.199 questions. It's fine. I'm happy to answer them. And we can
+00:17:22.200 --> 00:17:25.879 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?
+00:17:25.880 --> 00:17:30.239 Okay, why is it not feasible for the Emacs layer that
+00:17:30.240 --> 00:17:34.319 interprets Emacs Lisp, the core in C, have a Scheme
+00:17:34.320 --> 00:17:39.799 interpreter instead of using Guile? Let's see, I have to,
+00:17:39.800 --> 00:17:48.799 okay. Emacs layer interprets Emacs Lisp, the core in C, have
+00:17:48.800 --> 00:17:54.079 a Scheme interpreter instead of using Guile. Okay, so that,
+00:17:54.080 --> 00:17:59.959 the question xlarsx is asking, xlars, x, So Lars is asking,
+00:17:59.960 --> 00:18:02.319 is it not feasible for there to be an
+00:18:02.320 --> 00:18:06.839 Emacs layer that interprets Emacs Lisp have a scheme
+00:18:06.840 --> 00:18:33.079 interpreter? This is Robin Templeton's project. And
+00:18:33.080 --> 00:18:39.839 they're presenting later today. So check the roster and be
+00:18:39.840 --> 00:18:45.199 sure to see that presentation because that's exactly what
+00:18:45.200 --> 00:18:52.119 Robin Templeton is doing. That's not what I'm doing though.
+00:18:52.120 --> 00:18:57.239 I'm trying to create something in Scheme. But yes, there is
+00:18:57.240 --> 00:19:02.959 an attempt to get an Scheme interpreter to run inside of
+00:19:02.960 --> 00:19:07.159 Emacs itself. And it has its own method of binding to Emacs
+00:19:07.160 --> 00:19:11.199 Lisp functions and translating data like Lisp structures
+00:19:11.200 --> 00:19:14.439 between Guile Scheme and Emacs Lisp. Robin will explain all
+00:19:14.440 --> 00:19:15.799 of that in their presentation.
+00:19:15.800 --> 00:19:18.919 OK, I think I've got through all the questions on Etherpad.
+00:19:18.920 --> 00:19:23.879 But I'm going to hang out here for a bit longer. And yeah, feel
+00:19:23.880 --> 00:19:28.239 free to do a video chat with me or send me more questions on
+00:19:28.240 --> 00:19:33.839 Etherpad or here in the big blue button. And so I'm just going
+00:19:33.840 --> 00:21:49.119 to hang out. And thanks for asking all your questions. And
+00:21:49.120 --> 00:21:50.839 yeah, I look forward to working with all of you if you're
+00:21:50.840 --> 00:21:51.799 interested. take it easy. Thanks so much for the talk and
+00:21:51.800 --> 00:21:53.199 looking forward to seeing some of your progress as this
+00:21:53.200 --> 00:21:54.359 moves forward, exciting space. We'll go ahead and leave the
+00:21:54.360 --> 00:21:54.879 room open for you and thanks for offering to hang out and chat
+00:21:54.880 --> 00:21:55.639 with other people that come by. Feel free to throw something
+00:21:55.640 --> 00:21:56.719 in the chat if you want to remind people you're still here.
+00:21:56.720 --> 00:21:57.919 Meanwhile, on the stream, we have moved along to our next
+00:21:57.920 --> 00:21:59.599 talk on Rust, and that is just getting started. But again,
+00:21:59.600 --> 00:22:00.479 we're continuing to record this, and I'll just keep an eye on
+00:22:00.480 --> 00:22:01.239 it to stop the recording. Thank you. Thank you. It was
+00:22:01.240 --> 00:22:01.559 awesome.
+00:22:01.560 --> 00:22:03.959 So it seems like it's slowed down here for the Q&A. I don't see
+00:22:03.960 --> 00:22:05.439 anybody else on BBB, so I'm going to go ahead and stop the
+00:22:05.440 --> 00:22:08.479 recording. We can start it back up. I would say, yes, there's
+00:22:08.480 --> 00:22:09.519 a lot of things you can do with this. You can handle
+00:22:09.520 --> 00:22:11.239 processing. Yeah, I'm going to try and join over the chat for
+00:22:11.240 --> 00:22:14.679 the next talk. I'm not sure if I can do both big blue buttons at
+00:22:14.680 --> 00:22:15.759 the same time. You should be able to just watch your mute
+00:22:15.760 --> 00:22:19.159 settings and mute tab settings and whatever all you have to
+00:22:19.160 --> 00:23:37.800 avoid bleed through. Okay. -- cgit v1.2.3