WEBVTT timed by sachac, captioned by ramin 00:00:00.000 --> 00:00:02.780 Hi, my name is Ramin Honary, 00:00:02.781 --> 00:00:04.480 and I'm here to talk to you today 00:00:04.481 --> 00:00:08.940 about my clone of Emacs and Emacs Lisp that I've written in 00:00:08.941 --> 00:00:12.980 Scheme so far. 00:00:12.981 --> 00:00:19.102 So I am an Emacs enthusiast since 2017, 00:00:19.103 --> 00:00:22.664 currently employed as a full stack developer, 00:00:22.665 --> 00:00:25.225 mostly working with Python and JavaScript, 00:00:25.226 --> 00:00:27.079 although my true love is functional 00:00:27.080 --> 00:00:30.559 programming, especially Haskell, and Scheme. I started 00:00:30.560 --> 00:00:33.679 learning Scheme about two years ago. And for the past year, 00:00:33.680 --> 00:00:36.279 I've been working on a project that I'm tentatively calling 00:00:36.280 --> 00:00:40.794 Gypsum. Naming things is hard. It's not a great name. 00:00:40.795 --> 00:00:43.376 I'm open to suggestions. 00:00:43.377 --> 00:00:45.897 But yes, this is the project in which 00:00:45.898 --> 00:00:53.319 I am trying to write an Emacs Lisp interpreter in Scheme. 00:00:53.320 --> 00:00:58.199 There are many clones already of Emacs. You've probably 00:00:58.200 --> 00:01:04.799 heard of Edwin, Jed, Jedit, Jove, Lem, MG, Yi, Zile. Edwin 00:01:04.800 --> 00:01:10.519 itself is also written in Scheme--MIT Scheme. These only 00:01:10.520 --> 00:01:16.159 clone the key bindings of Emacs and not Emacs Lisp itself. 00:01:16.160 --> 00:01:21.199 The only alternative to GNU Emacs that I'm aware of is 00:01:21.200 --> 00:01:26.679 XEmacs, which is a fork of GNU Emacs. 00:01:26.680 --> 00:01:30.359 Most people don't use Emacs for the key bindings. I mean, 00:01:30.360 --> 00:01:34.039 this is anecdotally speaking, but the people who I've 00:01:34.040 --> 00:01:39.519 talked to, I would say don't use Emacs for the key bindings. 00:01:39.520 --> 00:01:42.679 They use it really more because of the power of Emacs Lisp. 00:01:42.680 --> 00:01:48.439 Emacs is as powerful as any system shell, perhaps even more 00:01:48.440 --> 00:01:53.105 powerful than system shells like Bash. 00:01:53.106 --> 00:01:55.207 The reason why it's so powerful is because 00:01:55.208 --> 00:01:56.959 there's a good programming language 00:01:56.960 --> 00:02:00.039 which you can use to control everything on your system. You 00:02:00.040 --> 00:02:01.732 can control processes. You can load and save files. 00:02:01.733 --> 00:02:06.416 You can create files. You can configure things. 00:02:06.417 --> 00:02:10.219 You can capture the output of processes in buffers. 00:02:10.220 --> 00:02:13.421 You can filter text through buffers. 00:02:13.422 --> 00:02:17.839 And a good programming language is what 00:02:17.840 --> 00:02:23.479 you need in order to do all of this. So one big goal of this 00:02:23.480 --> 00:02:29.239 project is to try to stick as closely as possible to the R7RS 00:02:29.240 --> 00:02:33.859 standard Scheme definition. That is the latest Scheme 00:02:33.860 --> 00:02:38.919 standard: R7. And this is just because I want my project to 00:02:38.920 --> 00:02:43.519 work on many scheme implementations, not just Guile. 00:02:43.520 --> 00:02:45.499 Although Guile certainly is the reference 00:02:45.500 --> 00:02:50.239 implementation. 00:02:50.240 --> 00:02:56.459 So another goal is to be able to run any "init.el". 00:02:56.460 --> 00:02:59.740 So you can take your existing "init.el" 00:02:59.741 --> 00:03:01.720 and run it in my program without 00:03:01.721 --> 00:03:05.340 significant changes. That's one of my goals in the end. 00:03:05.341 --> 00:03:07.315 I should be able to do that. 00:03:07.316 --> 00:03:09.119 A lot of people invest significant 00:03:09.120 --> 00:03:12.717 time in their configs, and it's kind of disruptive 00:03:12.718 --> 00:03:14.300 if you want to change editors, 00:03:14.301 --> 00:03:16.500 not be able to use your Emacs Lisp 00:03:16.501 --> 00:03:21.646 config. And so I think a useful Emacs clone 00:03:21.647 --> 00:03:25.127 would be able to clone Emacs Lisp well enough 00:03:25.128 --> 00:03:29.799 that you can run your "init.el". 00:03:29.800 --> 00:03:33.879 And so overall, why am I doing this? It's just because I like 00:03:33.880 --> 00:03:37.999 the Scheme programming language. I love its simplicity and 00:03:38.000 --> 00:03:42.439 its power. It's an extremely well thought-out language. 00:03:42.440 --> 00:03:46.159 It's one of those languages where you can understand the 00:03:46.160 --> 00:03:48.739 entire language from top to bottom. You can read the entire 00:03:48.740 --> 00:03:52.879 specification and understand it yourself. 00:03:52.880 --> 00:03:57.239 It's like the computers I grew up with when I was a kid. 00:03:57.240 --> 00:03:59.319 They were all very simple computers 00:03:59.320 --> 00:04:02.559 in the late 80s, early 90s. And back then, 00:04:02.560 --> 00:04:05.579 theoretically, an engineer could understand the entire 00:04:05.580 --> 00:04:07.959 system at the software level all the way down to the circuit 00:04:07.960 --> 00:04:12.159 level. You can't do that nowadays. And so nowadays, my 00:04:12.160 --> 00:04:16.859 computer is not really a physical computer anymore. It's 00:04:16.860 --> 00:04:21.079 the Scheme language standard itself. That is the core of 00:04:21.080 --> 00:04:25.599 computation, of all of computation for me. And I would like 00:04:25.600 --> 00:04:30.579 to use it as more than just an academic curiosity. It was 00:04:30.580 --> 00:04:36.359 originally designed for teaching at MIT, but it's found use 00:04:36.360 --> 00:04:41.399 in industry. And the R7RS standard is still 00:04:41.400 --> 00:04:44.270 relatively new. It's over 10 years old at this point, 00:04:44.271 --> 00:04:47.999 but hasn't, I mean, the 00:04:48.000 --> 00:04:52.980 Scheme ecosystem itself is already fairly small. 00:04:52.981 --> 00:04:54.341 There still, I don't think, 00:04:54.342 --> 00:04:56.359 has been a whole lot of adoption of R7RS 00:04:56.360 --> 00:04:58.785 quite yet. Kind of a shame. 00:04:58.786 --> 00:05:01.119 So I'd like a project like this, a 00:05:01.120 --> 00:05:04.009 very large scale, kind of a killer-app-like project 00:05:04.010 --> 00:05:05.920 where you're developing a text editor 00:05:05.921 --> 00:05:09.060 and perhaps even an integrated development environment 00:05:09.061 --> 00:05:11.920 in Scheme, I think would be very useful 00:05:11.921 --> 00:05:13.799 just even as a study of, you know, what 00:05:13.800 --> 00:05:18.461 can this language do? And just overall, 00:05:18.462 --> 00:05:21.220 there seems to be a lot of interest in 00:05:21.221 --> 00:05:24.320 Guile-based Emacs and well, maybe a 00:05:24.321 --> 00:05:27.163 Scheme-based Emacs, but Guile in particular. 00:05:27.164 --> 00:05:28.220 There has been talk of 00:05:28.221 --> 00:05:33.660 changing Emacs Lisp or the core of the Emacs Lisp over to 00:05:33.661 --> 00:05:38.469 Guile for about 30 years or so, 00:05:38.470 --> 00:05:41.199 talks originally in the early 00:05:41.200 --> 00:05:44.799 mid 90s. There were discussions between Richard Stallman, 00:05:44.800 --> 00:05:49.919 Tom Lord, and Aubrey Jaffer. They considered 00:05:49.920 --> 00:05:53.219 actually replacing Emacs Lisp with Scheme. 00:05:53.220 --> 00:05:56.827 In 1999, and going for about 10 years, 00:05:56.828 --> 00:06:01.079 someone named Ken Raeburn actually started 00:06:01.080 --> 00:06:07.240 a project where he started writing Emacs in Guile. 00:06:07.241 --> 00:06:11.859 My project is very similar to this. 00:06:11.860 --> 00:06:15.120 Here's a quote from his webpage, which is still up, even 00:06:15.121 --> 00:06:18.399 though it hasn't been updated in 15 years. 00:06:18.400 --> 00:06:20.519 This project that I have started 00:06:20.520 --> 00:06:23.101 is for converting GNU Emacs to Guile 00:06:23.102 --> 00:06:24.121 as its programming language. 00:06:24.122 --> 00:06:26.082 Support for Emacs Lisp will continue to exist, 00:06:26.083 --> 00:06:27.760 of course, but it may be through 00:06:27.761 --> 00:06:29.244 translation and/or interpretation. 00:06:29.245 --> 00:06:30.339 The Lisp engine itself 00:06:30.340 --> 00:06:32.906 may no longer be the core of the program. 00:06:32.907 --> 00:06:38.538 And this is my goal as well. In 2010, 00:06:38.539 --> 00:06:41.879 Andy Wingo and Ludovic Courtes 00:06:41.880 --> 00:06:46.402 took maintainership of the Guile project. 00:06:46.403 --> 00:06:52.719 From 2009, so while Andy... 2009 00:06:52.720 --> 00:06:59.399 to 2011, the first Emacs Lisp interpreter was already being 00:06:59.400 --> 00:07:02.089 implemented in Guile. And even to this day, 00:07:02.090 --> 00:07:05.651 this Emacs Lisp interpreter ships with Guile. 00:07:05.652 --> 00:07:06.599 And so this was happening 00:07:06.600 --> 00:07:10.112 while Andy Wingo took control of the project. 00:07:10.113 --> 00:07:13.833 In 2011, so shortly after Andy Wingo 00:07:13.834 --> 00:07:15.119 took control of the project, 00:07:15.120 --> 00:07:22.279 Guile 2.0 was released. And also in 2011, in the summertime, 00:07:22.280 --> 00:07:27.279 someone named Robin Templeton, I believe it was a Google 00:07:27.280 --> 00:07:33.519 Summer of Code project, started actually trying to 00:07:33.520 --> 00:07:38.719 incorporate libguile, that's the guile interpreter, as a 00:07:38.720 --> 00:07:45.199 linkable or loadable library, linking it to the Emacs 00:07:45.200 --> 00:07:49.179 executable, and then providing some built-in functions in 00:07:49.180 --> 00:07:54.759 Emacs that allows you to call the scheme 00:07:54.760 --> 00:07:58.739 interpreter, the Guile Scheme interpreter, from Emacs. 00:07:58.740 --> 00:08:02.239 And so it's not like a wrapper around the REPL like Geiser or 00:08:02.240 --> 00:08:08.959 SLIME. It's actually the whole Scheme interpreter loaded 00:08:08.960 --> 00:08:13.939 into your Emacs process. And that means your Emacs will have 00:08:13.940 --> 00:08:20.079 the ability to actually load compiled Scheme programs and 00:08:20.080 --> 00:08:25.879 actually run them and share memory with Emacs Lisp 00:08:25.880 --> 00:08:29.799 processes. And, well, Robin Templeton will explain all of 00:08:29.800 --> 00:08:33.039 this. They're presenting today, and I'm very excited to 00:08:33.040 --> 00:08:37.079 actually see their presentation. They'll explain 00:08:37.080 --> 00:08:40.179 everything. 00:08:40.180 --> 00:08:45.679 So, let's see. Moving on. 2020, someone named Vasilij 00:08:45.680 --> 00:08:49.039 Schneidermann, I'm not sure how you pronounce that, published 00:08:49.040 --> 00:08:53.639 an overview called The State of Emacs Lisp on Guile. Let's see 00:08:53.640 --> 00:08:58.399 if I have that here. Yep, it's this page right here. He goes 00:08:58.400 --> 00:09:04.879 into detail about who has done what so far, and what can you do 00:09:04.880 --> 00:09:09.759 in Guile with Emacs Lisp so far, and so on. Like, what is the 00:09:09.760 --> 00:09:12.717 state of the project overall? 00:09:12.718 --> 00:09:15.899 And so (speak of the devil) 00:09:15.900 --> 00:09:20.960 (Andy Wingo on social media). 00:09:20.961 --> 00:09:24.339 So, 2020 to present. Guile Emacs 00:09:24.340 --> 00:09:32.071 is dead? So there's GCC Emacs now. 00:09:32.072 --> 00:09:35.752 Emacs Lisp now has its own JIT compiler. 00:09:35.753 --> 00:09:39.259 And it seems like over the past few years, 00:09:39.260 --> 00:09:44.319 Emacs Lisp has kind of moved off into the direction of 00:09:44.320 --> 00:09:48.439 becoming its own programming language in its own right, 00:09:48.440 --> 00:09:51.839 and it is decidedly Common Lisp-flavored. It is 00:09:51.840 --> 00:09:54.166 very similar to Common Lisp, 00:09:54.167 --> 00:09:56.519 and that seems to be the direction 00:09:56.520 --> 00:10:00.719 that it's headed now, and I don't know if there's really any 00:10:00.720 --> 00:10:05.559 interest anymore amongst the Emacs maintainers of 00:10:05.560 --> 00:10:09.799 continuing with a Guile-based Emacs. 00:10:09.800 --> 00:10:13.319 But as far as I know, there's still a lot of interest in the 00:10:13.320 --> 00:10:19.599 community amongst Scheme and Lisp and Emacs users who are 00:10:19.600 --> 00:10:24.779 interested in maybe continuing to try to get Guile to become 00:10:24.780 --> 00:10:28.079 the core of Emacs, or if not, you know, what Robin Templeton 00:10:28.080 --> 00:10:31.639 has been doing, at least trying to get Guile a 00:10:31.640 --> 00:10:37.279 language, a first class supported language in Emacs. So 00:10:37.280 --> 00:10:39.999 that's enough talking. Let me just show you what I have so 00:10:40.000 --> 00:10:45.239 far. The GUI is barely working, because I have very little 00:10:45.240 --> 00:10:50.039 experience with GTK or GObject Introspection. It's very 00:10:50.040 --> 00:10:53.639 difficult to debug, so it's very slow to develop. Any crash 00:10:53.640 --> 00:10:58.199 at C level produces no stack traces. So far, most of the 00:10:58.200 --> 00:11:03.199 crashes that I've experienced are due to simple mistakes 00:11:03.200 --> 00:11:09.399 like passing the wrong data type. So, so far, no, not a whole 00:11:09.400 --> 00:11:14.174 lot of need for GDB or rebuilding all GTK, glib, 00:11:14.175 --> 00:11:17.877 and so on with the debugging symbols. 00:11:17.878 --> 00:11:19.319 But yes, still development's been 00:11:19.320 --> 00:11:25.499 very slow. I'm learning as I go. I've chosen to use Guile GI as 00:11:25.500 --> 00:11:30.499 the foundation for the GUI. Let me just load it up quick here. 00:11:30.600 --> 00:11:39.899 "load main-guile.scm". And this will launch the GUI. I also 00:11:39.900 --> 00:11:44.199 happen to have a REPL that runs in a separate thread and 00:11:44.200 --> 00:11:49.759 submits any form that you type to be evaluated inside of the 00:11:49.760 --> 00:11:57.079 running GUI environment. But you can just type stuff. So 00:11:57.080 --> 00:12:02.903 "hello world." And of course there is... 00:12:02.904 --> 00:12:08.059 as you can see, it's not quite rendering correctly. 00:12:08.060 --> 00:12:11.090 This "*Messages*" thing here, 00:12:11.091 --> 00:12:13.760 that should be over here, obviously. I haven't been able to 00:12:13.761 --> 00:12:17.820 figure out how to get those little details down. But yeah, 00:12:17.821 --> 00:12:23.215 you can do M-:, and you get your eval, 00:12:23.216 --> 00:12:26.637 and you can just evaluate, like (what's an emacs,) 00:12:26.638 --> 00:12:29.280 (or what's a Scheme-specific thing?) 00:12:29.281 --> 00:12:37.679 Like "(import (srfi 1))", and 00:12:37.680 --> 00:12:44.888 let's see, do "(iota 20)", for example. 00:12:44.889 --> 00:12:46.780 And so that is the procedure 00:12:46.781 --> 00:12:52.900 that iterates and produces some 20 elements of a 00:12:52.901 --> 00:12:58.419 list. Or you can do something like, let's see, 00:12:58.420 --> 00:13:08.114 string-append "hello" with space "world". 00:13:08.115 --> 00:13:10.259 And you get the result and so on. And, 00:13:10.260 --> 00:13:13.039 you know, scheme allows you to return multiple values. So 00:13:13.040 --> 00:13:14.998 what I have done here is just 00:13:14.999 --> 00:13:17.979 every value is captured in a list 00:13:17.980 --> 00:13:21.001 and it prints all of the return values in the list. 00:13:21.002 --> 00:13:23.462 So if a procedure returns no values, 00:13:23.463 --> 00:13:26.144 you get an empty list. 00:13:26.145 --> 00:13:29.405 And that's that. It's still quite buggy. 00:13:29.406 --> 00:13:31.519 So like, here's a bug 00:13:31.520 --> 00:13:37.319 that I can reproduce fairly consistently. 00:13:37.320 --> 00:13:41.407 I can, yeah, if you do... 00:13:41.408 --> 00:13:46.199 there seems to be a problem with a 00:13:46.200 --> 00:13:49.719 widget being freed too soon, so it will crash. I'm going to 00:13:49.720 --> 00:13:53.319 try and solve that, hopefully, before this presentation 00:13:53.320 --> 00:13:57.109 goes live. Let's see here. 00:13:57.110 --> 00:13:59.839 The Emacs Lisp parser is based on 00:13:59.840 --> 00:14:04.399 Guile Emacs Lisp. So the Guile Emacs Lisp interpreter that 00:14:04.400 --> 00:14:09.039 ships with Guile, that is what I am using. I've actually 00:14:09.040 --> 00:14:15.719 copied and pasted the source code from the Guile source base 00:14:15.720 --> 00:14:20.639 into my own project so that I can iterate on it more quickly. 00:14:20.640 --> 00:14:25.799 And I've already had to make some modifications to the 00:14:25.800 --> 00:14:29.899 Emacs Lisp interpreter in Guile. So here's the evaluator. 00:14:29.900 --> 00:14:33.079 I've actually already modified the parser and the lexer a 00:14:33.080 --> 00:14:37.858 little bit. And it's at least able to parse 00:14:37.859 --> 00:14:43.149 all of the "subr.el" program, the Emacs Lisp program. 00:14:43.150 --> 00:14:44.599 It can actually load that, but not 00:14:44.600 --> 00:14:47.570 evaluate it, or parse it, but not evaluate it... 00:14:47.571 --> 00:14:51.719 Read, not eval. 00:14:51.720 --> 00:14:53.959 By the time this goes live, I will have submitted a patch 00:14:53.960 --> 00:14:57.559 upstream. And that's another goal of this project, 00:14:57.560 --> 00:15:01.199 incidentally, is that anything that we can contribute to 00:15:01.200 --> 00:15:08.359 Guile and any built-in functions that we can implement 00:15:08.360 --> 00:15:10.999 I would like to, for this project, I would like to try and 00:15:11.000 --> 00:15:15.679 contribute upstream to Guile. The Emacs Lisp interpreter 00:15:15.680 --> 00:15:21.359 is not working well, unfortunately. So this copy, this is 00:15:21.360 --> 00:15:29.479 the copy of the code base (from this commit in particular) 00:15:29.480 --> 00:15:34.979 and well, I can't get it working. I can't actually get the 00:15:34.980 --> 00:15:37.759 non-copy, the actual built-in version of 00:15:37.760 --> 00:15:41.211 the Emacs Lisp interpreter to work properly quite yet. 00:15:41.212 --> 00:15:47.033 So let me quick go to, (what is this here?) 00:15:47.034 --> 00:15:51.879 Guile Elisp. So suppose you have this 00:15:51.880 --> 00:15:55.999 "eval-elisp" procedure here and it takes 00:15:56.000 --> 00:16:00.639 an Elisp environment and then it evaluates an expression in that 00:16:00.640 --> 00:16:03.599 environment. And evaluates to a value. So this 00:16:03.600 --> 00:16:05.084 is the standard way of doing it in Guile. 00:16:05.085 --> 00:16:06.039 If you can see here, 00:16:06.040 --> 00:16:09.946 you've got this expression, "compile" expression. 00:16:09.947 --> 00:16:16.859 This is like "eval". And so actually trying to load this. 00:16:16.860 --> 00:16:24.672 So let's do "load gypsum". (Let's see here. This is, no), 00:16:24.673 --> 00:16:35.759 I wanted to "import gypsum backend guile Elisp". 00:16:35.760 --> 00:16:39.039 And if I actually want to do this... So elisp eval, first of all, 00:16:39.040 --> 00:16:42.879 it says it failed because there's an unbound variable 00:16:42.880 --> 00:16:45.348 "elisp-eval". Don't know what it's talking about. 00:16:45.349 --> 00:16:48.229 There's no such variable in any of my programs. 00:16:48.230 --> 00:16:51.151 I have no idea what's going on here. 00:16:51.152 --> 00:16:59.279 You can try to run eval elisp on some simple form like 00:16:59.280 --> 00:17:04.759 (+ 1 2). And it gives you this exception. This works. 00:17:04.760 --> 00:17:09.579 This is the same issue that I have with all of the, 00:17:09.580 --> 00:17:13.200 every version of the Emacs Lisp Interpreter in Guile. 00:17:13.201 --> 00:17:18.751 I can get it to work with this big ",L" mode. 00:17:18.752 --> 00:17:21.593 So I can actually do (+ 1 2) here. 00:17:21.594 --> 00:17:26.816 I can do "princ" like here. 00:17:26.817 --> 00:17:30.119 That all works fine. It gives me, for some reason, 00:17:30.120 --> 00:17:34.940 a stack trace here. 00:17:34.941 --> 00:17:43.926 And yeah, so it's a bit, it's not well-documented. 00:17:43.927 --> 00:17:45.887 The code base is fairly old. 00:17:45.888 --> 00:17:50.399 As I said, it was developed around 2011, 00:17:50.400 --> 00:17:53.239 and it's fairly opaque, and I have not been able to figure out 00:17:53.240 --> 00:17:57.959 how to get Emacs Lisp in Guile working smoothly. So I have 00:17:57.960 --> 00:18:04.539 started writing my own Emacs Lisp interpreter. And, uh, 00:18:04.540 --> 00:18:13.399 "gypsum/elisp/eval-tests.scm". 00:18:13.400 --> 00:18:18.269 It's, uh, not entirely ready. 00:18:18.270 --> 00:18:21.695 I can show you some of the tests at least. 00:18:21.696 --> 00:18:25.036 Here is a simple Emacs Lisp program 00:18:25.037 --> 00:18:25.856 that you can evaluate. 00:18:25.857 --> 00:18:31.139 You got "progn", "setq" a to 3, "setq" b to 5, 00:18:31.140 --> 00:18:35.839 "setq" c to the sum of a and b, return c. 00:18:35.840 --> 00:18:39.059 And this at least works correctly. 00:18:39.060 --> 00:18:43.279 As you can see here, the result is eight. Um, but 00:18:43.280 --> 00:18:46.520 the "let*" semantics are not completed yet. 00:18:46.521 --> 00:18:51.103 Lots of work left to do there. 00:18:51.104 --> 00:18:54.464 So in the time I have left, I guess I can just, 00:18:54.465 --> 00:18:56.759 talk a little bit about what my plans 00:18:56.760 --> 00:18:59.387 are for the future. 00:18:59.388 --> 00:19:02.599 I would like to begin by evaluating or 00:19:02.600 --> 00:19:06.759 actually loading the "subr.el" into my Emacs Lisp 00:19:06.760 --> 00:19:09.639 interpreter. I actually have tests set up for that as well, 00:19:09.640 --> 00:19:15.909 so I can actually select any form I want from "subr.el". 00:19:15.910 --> 00:19:18.832 I can just run this through my interpreter 00:19:18.833 --> 00:19:21.593 and test to see if everything is working 00:19:21.594 --> 00:19:28.779 once I get that far. 00:19:28.780 --> 00:19:33.239 And yeah, let me just say that this is my formal appeal to the 00:19:33.240 --> 00:19:37.799 community for help on this project. Emacs Lisp has 00:19:37.800 --> 00:19:41.179 1,393 built-in functions. 00:19:41.180 --> 00:19:45.039 I could never implement that many functions on my own, so if 00:19:45.040 --> 00:19:47.599 this project is going to be useful to anybody in any 00:19:47.600 --> 00:19:51.114 reasonable amount of time, I'm going to need help. 00:19:51.115 --> 00:19:53.476 And I know that there are people out there 00:19:53.477 --> 00:19:56.398 who are very interested in a Guile-based Emacs, 00:19:56.399 --> 00:19:58.999 and so if you're watching this, 00:19:59.000 --> 00:20:00.521 please feel free to contact me 00:20:00.522 --> 00:20:05.699 on social media or over e-mail. 00:20:05.700 --> 00:20:09.647 My job, the way I see it, is if there's enough interest, 00:20:09.648 --> 00:20:12.064 and I do get a lot of people interested in 00:20:12.065 --> 00:20:13.199 starting to contribute, 00:20:13.200 --> 00:20:17.919 my job will be to document the building and testing process 00:20:17.920 --> 00:20:21.039 and make sure that it is as easy as possible to contribute 00:20:21.040 --> 00:20:24.079 code to this project. I want to document the system 00:20:24.080 --> 00:20:27.599 architecture. I'll write blog posts. I'll do videos on 00:20:27.600 --> 00:20:31.879 PeerTube explaining how everything works. And I will 00:20:31.880 --> 00:20:34.199 prioritize which built-in functions 00:20:34.200 --> 00:20:36.462 I think are probably going to be the most necessary, 00:20:36.463 --> 00:20:40.878 the most essential to get the interpreter running, 00:20:40.879 --> 00:20:42.559 and then find low-hanging fruit, 00:20:42.560 --> 00:20:46.519 functions that are easy for people to implement 00:20:46.520 --> 00:20:50.845 as a good introduction to getting them started 00:20:50.846 --> 00:20:53.947 on contributing to the project. 00:20:53.948 --> 00:20:56.679 And then, of course, I will take 00:20:56.680 --> 00:21:01.719 responsibility myself of making sure that we can 00:21:01.720 --> 00:21:03.774 get the Elisp interpreter to the point 00:21:03.775 --> 00:21:09.079 where it can run the Emacs regression tests. 00:21:09.080 --> 00:21:13.333 These are the test suites that are used 00:21:13.334 --> 00:21:20.359 to test Emacs Lisp itself in the GNU Emacs code base. And so 00:21:20.360 --> 00:21:24.559 ERT is itself written in Emacs Lisp. And so 00:21:24.560 --> 00:21:27.033 I think if we implement enough of the built-in functions 00:21:27.034 --> 00:21:29.933 to be able to run ERT, 00:21:29.934 --> 00:21:31.195 then we can actually start 00:21:31.196 --> 00:21:33.617 using the GNU Emacs regression tests 00:21:33.618 --> 00:21:39.248 to test our own interpreter, our own Emacs clone. 00:21:39.249 --> 00:21:41.199 And of course, I'll make sure that there's at least 00:21:41.200 --> 00:21:45.833 one usable GUI. I'm currently working on Guile GI 00:21:45.834 --> 00:21:51.396 and GTK. It would be great to have an... 00:21:51.397 --> 00:21:53.879 ANSI terminal based... 00:21:53.880 --> 00:21:58.219 something that works in your terminal emulator. 00:21:58.220 --> 00:22:00.283 And yeah, it would be great if someday soon, 00:22:00.284 --> 00:22:03.159 hopefully, we get enough done 00:22:03.160 --> 00:22:06.094 that you can actually contribute a patch to this project 00:22:06.095 --> 00:22:11.778 from within the Gypsum editor itself. 00:22:11.779 --> 00:22:13.380 I was going to do an overview, 00:22:13.381 --> 00:22:19.679 but that would be for more of an hour-long presentation. 00:22:19.680 --> 00:22:22.927 So I'm out of time. I guess the last thing 00:22:22.928 --> 00:22:25.449 I should quickly say is there's no 00:22:25.450 --> 00:22:27.159 meta object protocol in this 00:22:27.160 --> 00:22:29.001 project. I think that's a little bit too difficult 00:22:29.002 --> 00:22:30.962 to port to various scheme implementations. 00:22:30.963 --> 00:22:33.739 So I've created a substitute, which I'm 00:22:33.740 --> 00:22:36.959 calling "functional lenses", which is inspired by the 00:22:36.960 --> 00:22:42.059 Haskell project of the same name. 00:22:42.060 --> 00:22:47.511 Everything in this project is based on functional lenses. 00:22:47.512 --> 00:22:52.603 Yeah, also a lot a work went into the keymaps data structure. 00:22:52.604 --> 00:22:55.206 The point being that I think I have 00:22:55.207 --> 00:22:58.589 a pretty good foundation here upon which we can build, 00:22:58.590 --> 00:23:00.839 even though there isn't an actual, there isn't 00:23:00.840 --> 00:23:04.699 a lot done in the actual prototype itself, not yet anyway, 00:23:04.700 --> 00:23:08.419 but I made sure to get the fundamentals down 00:23:08.420 --> 00:23:11.080 from the beginning. And so I think we have something 00:23:11.081 --> 00:23:16.308 like a solid foundation on which to build. 00:23:16.309 --> 00:23:21.230 So, I'm going to conclude it there. 00:23:21.231 --> 00:23:24.599 And here's my contact details. Like I said, 00:23:24.600 --> 00:23:29.319 this is a project, I'm appealing to the community of all 00:23:29.320 --> 00:23:31.899 people who are interested in Guile and Emacs to help 00:23:31.900 --> 00:23:35.839 contribute to this project. I see myself as just getting the 00:23:35.840 --> 00:23:40.600 ball rolling. Again, taking-off from the work 00:23:40.601 --> 00:23:46.278 that Ken Raeburn left behind, with my own 00:23:46.279 --> 00:23:50.637 from-the-ground-up implementation. So yeah, 00:23:50.638 --> 00:23:53.858 contact me: e-mail, you can take a look at my blog 00:23:53.859 --> 00:23:57.419 where I talk about what I have done. 00:23:57.420 --> 00:24:00.759 My source code, the code for this project, is up on 00:24:00.760 --> 00:24:06.139 Codeberg... The presentation... this 00:24:06.140 --> 00:24:09.379 presentation, the home page for this presentation, you 00:24:09.380 --> 00:24:15.559 can find more details there. Oh, I'm on 00:24:15.560 --> 00:24:19.139 ActivityPub as well, so my handle is 00:24:19.140 --> 00:24:27.119 @ramin_hal9001@fe.disroot.org, and I'm on everyday. 00:24:27.120 --> 00:24:30.939 So yeah, please feel free to contact me if you're interested, 00:24:30.940 --> 00:24:35.640 and thank you for your attention.