diff options
Diffstat (limited to '2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt')
| -rw-r--r-- | 2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt | 1007 |
1 files changed, 607 insertions, 400 deletions
diff --git a/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt index b4e7cdc8..1c952084 100644 --- a/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt +++ b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt @@ -1,601 +1,808 @@ -WEBVTT captioned by sachac and robin +WEBVTT captioned by anush -00:00:00.000 --> 00:00:03.839 -Hello everyone. I'm Robin Templeton, and I'm going to talk +00:00.000 --> 00:03.066 +Hello everyone, I'm Robin Templeton, -00:00:03.840 --> 00:00:07.919 -about Emacs Beguiled and recent progress on the Guile-Emacs +00:03.083 --> 00:05.750 +and I'm going to talk about Emacs Beguiled -00:00:07.920 --> 00:00:13.919 -project. +00:05.766 --> 00:13.866 +and recent progress on the Guile Emacs project. -00:00:13.920 --> 00:00:16.839 -First of all, if you're not familiar with Guile, it's an +00:13.883 --> 00:16.433 +First of all, if you're not familiar with Guile, -00:00:16.840 --> 00:00:20.239 -implementation of the Scheme programming language, which +00:16.450 --> 00:19.716 +it's an implementation of the Scheme programming language, -00:00:20.240 --> 00:00:24.799 -is a dialect of Lisp, and in the same family as Emacs Lisp, and +00:19.733 --> 00:22.150 +which is a dialect of Lisp, -00:00:24.800 --> 00:00:28.759 -Guile is GNU's official extension language. The goal of +00:22.166 --> 00:24.550 +and in the same family as Emacs Lisp, -00:00:28.760 --> 00:00:32.679 -the Guile-Emacs project is to use Guile as the basis for +00:24.566 --> 00:28.150 +and Guile is GNU's official extension language. -00:00:32.680 --> 00:00:37.599 -Emacs's Lisp support. It has two main components: a new +00:28.166 --> 00:30.400 +The goal of the Guile Emacs project -00:00:37.600 --> 00:00:41.919 -Emacs Lisp compiler built on top of Guile, and a variant of +00:30.400 --> 00:34.950 +is to use Guile as the basis for Emacs's Lisp support. -00:00:41.920 --> 00:00:45.199 -Emacs in which the built-in Lisp implementation is +00:34.966 --> 00:37.116 +It has two main components: -00:00:45.200 --> 00:00:50.239 -entirely replaced with Guile Elisp. We expect the +00:37.133 --> 00:41.033 +a new Emacs Lisp compiler built on top of Guile, -00:00:50.240 --> 00:00:53.439 -combination of these two projects to have several +00:41.050 --> 00:42.550 +and a variant of Emacs -00:00:53.440 --> 00:00:57.999 -benefits. One is improved performance. Another is +00:42.566 --> 00:45.316 +in which the built-in Lisp implementation -00:00:58.000 --> 00:01:03.839 -increased expressiveness for Elisp and making it easier to +00:45.333 --> 00:49.716 +is entirely replaced with Guile Elisp. -00:01:03.840 --> 00:01:07.839 -extend and experiment with the language. Finally, it +00:49.733 --> 00:52.800 +We expect the combination of these two projects -00:01:07.840 --> 00:01:13.079 -will reduce Emacs's reliance on C for two reasons. Guile will +00:52.800 --> 00:57.350 +to have several benefits. One is improved performance. -00:01:13.080 --> 00:01:16.959 -be responsible for the language implementation, so Emacs +00:57.366 --> 01:00.200 +Another is increased expressiveness for Elisp -00:01:16.960 --> 00:01:21.559 -will no longer have to include a Lisp interpreter. It +01:00.200 --> 01:04.350 +and making it easier to extend -00:01:21.560 --> 00:01:25.759 -will also become possible to implement much more of Emacs in +01:04.366 --> 01:07.200 +and experiment with the language. -00:01:25.760 --> 00:01:30.279 -Lisp than is currently feasible. Of course, this raises +01:07.200 --> 01:08.550 +Finally, it will reduce -00:01:30.280 --> 00:01:34.119 -the question of why Guile is suitable for this project. And +01:08.566 --> 01:12.316 +Emacs's reliance on C for two reasons. -00:01:34.120 --> 00:01:38.079 -we chose Guile for a few reasons. Guile is primarily a Scheme +01:12.333 --> 01:16.316 +Guile will be responsible for the language implementation, -00:01:38.080 --> 00:01:41.119 -implementation, but it also has built-in support for +01:16.333 --> 01:21.350 +so Emacs will no longer have to include a Lisp interpreter. -00:01:41.120 --> 00:01:44.399 -multiple languages using its compiler tower. To add +01:21.366 --> 01:23.200 +It will also become possible -00:01:44.400 --> 00:01:50.079 -support for a new language to Guile, you only have to write a +01:23.200 --> 01:25.666 +to implement much more of Emacs in Lisp -00:01:50.080 --> 00:01:53.399 -compiler from the source language to Tree-IL, which is +01:25.683 --> 01:29.233 +than is currently feasible. -00:01:53.400 --> 00:01:57.439 -essentially a low-level, minimal representation of +01:29.250 --> 01:31.116 +Of course, this raises the question of -00:01:57.440 --> 00:02:02.479 -Scheme. All of Guile's compiler optimizations occur at the +01:31.133 --> 01:34.033 +why Guile is suitable for this product. -00:02:02.480 --> 00:02:07.599 -Tree-IL layer or lower, so you don't need to worry about the +01:34.050 --> 01:36.666 +And we chose Guile for a few reasons. -00:02:07.600 --> 00:02:10.159 -lower-level details of the compiler when initially +01:36.683 --> 01:39.400 +Guile is primarily a Scheme implementation, -00:02:10.160 --> 00:02:14.639 -implementing your language. Guile also has some Lisp +01:39.400 --> 01:42.150 +but it also has built-in support for multiple languages -00:02:14.640 --> 00:02:18.879 -features that are very rare in Scheme implementations. For +01:42.166 --> 01:43.466 +using its compiler tower. -00:02:18.880 --> 00:02:22.599 -example, it has a nil value that counts as both false and an +01:43.483 --> 01:46.866 +To add support for a new language to Guile, -00:02:22.600 --> 00:02:27.759 -empty list, just like in Elisp, and it also has a version of +01:46.883 --> 01:50.066 +You only have to write a compiler -00:02:27.760 --> 00:02:32.319 -the Common Lisp Object System and its metaobject protocol, +01:50.083 --> 01:52.550 +from the source language to TRIAL[??], -00:02:32.320 --> 00:02:37.239 -which is called GOOPS. +01:52.566 --> 01:55.800 +which is essentially a low-level, -00:02:37.240 --> 00:02:42.199 -The idea of Guile-Emacs has a pretty long history, going back +01:55.800 --> 01:58.866 +minimal representation of Scheme. -00:02:42.200 --> 00:02:45.319 -at least three decades. There have been about half a dozen +01:58.883 --> 02:01.800 +All of Guile's compiler optimizations -00:02:45.320 --> 00:02:48.519 -previous implementation attempts. But the current +02:01.800 --> 02:04.433 +occur at the TRIAL[??] layer or lower, -00:02:48.520 --> 00:02:51.519 -iteration began with a series of six Summer of Code +02:04.450 --> 02:06.033 +so you don't need to worry -00:02:51.520 --> 00:02:56.279 -internships: Daniel Kraft's in 2009, and then my +02:06.050 --> 02:09.633 +about the lower-level details of the compiler -00:02:56.280 --> 00:03:02.519 -internships from 2010 to 2014. My basic implementation +02:09.650 --> 02:12.350 +when initially implementing your language. -00:03:02.520 --> 00:03:06.319 -strategy was pretty straightforward. I implemented a core +02:12.366 --> 02:14.633 +Guile also has some Lisp features -00:03:06.320 --> 00:03:09.679 -subset of Elisp, which was enough to run some batch mode +02:14.650 --> 02:18.316 +that are very rare in schema implementations. -00:03:09.680 --> 00:03:15.399 -programs outside of Emacs. In Emacs, I modified the garbage +02:18.333 --> 02:20.033 +For example, it has a nil value -00:03:15.400 --> 00:03:19.679 -collector and the data structures for Lisp objects to use +02:20.050 --> 02:23.916 +that counts as both false and an empty list, -00:03:19.680 --> 00:03:24.679 -their libguile equivalents. I replaced Emacs' Lisp +02:23.933 --> 02:25.633 +just like an Elisp, -00:03:24.680 --> 00:03:32.199 -evaluator with the one provided by Guile Elisp. +02:25.650 --> 02:30.466 +and it also has a version of the Common Lisp object system -00:03:32.200 --> 00:03:35.919 -After a little over a year of work, at the end of the 2014 +02:30.483 --> 02:37.200 +and its metoptic[??] protocol, which is called GOOPS. -00:03:35.920 --> 00:03:41.079 -internship, I ended up with a fully functional prototype of +02:37.200 --> 02:40.150 +The idea of Guile Emacs has a pretty long history. -00:03:41.080 --> 00:03:46.039 -Guile-Emacs. It used Guile Elisp alone as its Lisp +02:40.166 --> 02:43.866 +going back at least three decades. -00:03:46.040 --> 00:03:53.319 -implementation and was completely compatible with Emacs +02:43.883 --> 02:44.550 +There have been about -00:03:53.320 --> 00:03:57.559 -functionality and with external extensions. One caveat +02:44.566 --> 02:48.000 +half a dozen previous implementation attempts. -00:03:57.560 --> 00:04:01.399 -was that performance was pretty bad, because I was focused +02:48.000 --> 02:49.950 +But the current iteration began with -00:04:01.400 --> 00:04:05.639 -on correctness, as well as ease of integration with the +02:49.966 --> 02:52.866 +a series of six Summer of Code internships, -00:04:05.640 --> 00:04:10.559 -Emacs C code. But it was nonetheless a major milestone for +02:52.883 --> 02:56.033 +Daniel Kraft's[??] in 2009, -00:04:10.560 --> 00:04:15.759 -the project. Let's take just a moment to look at +02:56.050 --> 03:01.200 +and then my internships from 2010 to 2014. -00:04:15.760 --> 00:04:19.599 -Guile-Elisp. +03:01.200 --> 03:03.000 +My basic implementation strategy -00:04:19.600 --> 00:04:23.879 -For starters, we have access to Guile modules. If we call +03:03.000 --> 03:05.316 +was pretty straightforward. -00:04:23.880 --> 00:04:26.959 -Guile's <i>version</i> function, we can see that we're running +03:05.333 --> 03:07.466 +I implemented a core subset of Elisp, -00:04:26.960 --> 00:04:33.879 -under Guile 3.0. We have access to some of the numeric tower via +03:07.483 --> 03:10.400 +which was enough to run some batch mode programs -00:04:33.880 --> 00:04:41.279 -the arithmetic functions. We also have multiple values. We +03:10.400 --> 03:12.833 +outside of Emacs. -00:04:41.280 --> 00:04:45.599 -have to be careful to use Guile's <i>values</i> procedure here, not +03:12.850 --> 03:15.266 +In Emacs, I modified the garbage collector -00:04:45.600 --> 00:04:48.839 -the CL library's, but you can see that this works properly +03:15.283 --> 03:18.600 +and the data structures for Lisp objects -00:04:48.840 --> 00:04:52.879 -rather than being an emulation. Finally, we have tail +03:18.600 --> 03:23.033 +to use their libgal equivalents. -00:04:52.880 --> 00:04:57.999 -call elimination. Naturally, we're going to use factorial +03:23.050 --> 03:26.950 +I replaced Emacs' Lisp evaluator -00:04:58.000 --> 00:05:07.159 -to demonstrate it. If <i>n</i> is zero, return the answer, else +03:26.966 --> 03:32.200 +with the one provided by guile-elisp.[??] -00:05:07.160 --> 00:05:14.199 -recurse with <i>n</i> less one and <i>n</i> times <i>a</i>. +03:32.200 --> 03:34.033 +After a little over a year of work -00:05:14.200 --> 00:05:17.119 -Of course, this definition works correctly, but it gets +03:34.050 --> 03:37.950 +at the end of the 2014 internship, -00:05:17.120 --> 00:05:21.759 -more interesting if we communicate the answer with an +03:37.966 --> 03:44.316 +I ended up with a fully functional prototype of Guile Emacs. -00:05:21.760 --> 00:05:27.759 -error, +03:44.333 --> 03:48.916 +It used Guile Elisp alone as its Lisp implementation -00:05:27.760 --> 00:05:32.359 -in order to look at a backtrace. You can see here that there are no +03:48.933 --> 03:53.916 +and was completely compatible with Emacs functionality -00:05:32.360 --> 00:05:37.839 -calls to <i>fact</i> visible in between the request to evaluate and +03:53.933 --> 03:56.716 +and with external extensions. -00:05:37.840 --> 00:05:42.199 -the error communicating the answer. That's because +03:56.733 --> 03:59.433 +One caveat was that performance was pretty bad, -00:05:42.200 --> 00:05:53.319 -this tail call has been optimized into effectively a goto. +03:59.450 --> 04:03.033 +because I was focused on correctness, -00:05:53.320 --> 00:05:55.759 -This is essential for any kind of serious functional +04:03.050 --> 04:07.600 +as well as ease of integration with the Emacs C code. -00:05:55.760 --> 00:06:00.279 -programming. +04:07.600 --> 04:11.550 +But it was nonetheless a major milestone for the project. -00:06:00.280 --> 00:06:05.359 -That's a peek at Guile-Elisp. In 2015, I left university +04:11.566 --> 04:19.600 +Let's take just a moment to look at guile-elisp. -00:06:05.360 --> 00:06:09.479 -to go work on web technologies, and the project was dormant +04:19.600 --> 04:23.233 +For starters, we have access to guile modules. -00:06:09.480 --> 00:06:14.679 -for a very long time. But that's been changing recently. +04:23.250 --> 04:25.116 +If we call guile's version function, -00:06:14.680 --> 00:06:17.039 -During the last few months, I've been working with Larry +04:25.133 --> 04:30.516 +we can see that we're running under guile 3.0, -00:06:17.040 --> 00:06:23.399 -Valkama to rebase Guile-Emacs onto the development branch +04:30.533 --> 04:33.233 +have access to some of the numeric tower -00:06:23.400 --> 00:06:28.319 -of upstream Emacs, including the past decade's worth of +04:33.250 --> 04:39.516 +via the arithmetic functions. We also have multiple values. -00:06:28.320 --> 00:06:33.399 -upstream development. What we've ended up with is a series +04:39.533 --> 04:43.950 +We have to be careful to use Guile's values procedure here, -00:06:33.400 --> 00:06:38.839 -of rebases onto different versions of Emacs. The older ones +04:43.966 --> 04:46.666 +not the CL libraries, -00:06:38.840 --> 00:06:44.239 -tend to work pretty well. The newer ones have increasingly +04:46.683 --> 04:48.833 +but you can see that this works properly -00:06:44.240 --> 00:06:49.799 -bad problems where they haven't been properly adjusted for +04:48.850 --> 04:51.550 +rather than being an emulation. -00:06:49.800 --> 00:06:55.599 -changes in the Emacs implementation. But we do have by now a +04:51.566 --> 04:54.033 +Finally, we have tail call elimination. -00:06:55.600 --> 00:06:58.919 -version of Emacs 30 which boots correctly and can be used for +04:54.050 --> 05:02.866 +Naturally, we're going to use factorial to demonstrate it. -00:06:58.920 --> 00:07:04.959 -interactive debugging, as well as the ability to bisect the +05:02.883 --> 05:05.633 +If n is zero, return the answer, -00:07:04.960 --> 00:07:08.919 -revisions of Emacs and find out where regressions were +05:05.650 --> 05:14.266 +else recurse with n less one and n times a. -00:07:08.920 --> 00:07:13.199 -introduced. Our immediate goal is of course to complete +05:14.283 --> 05:16.150 +Of course this definition works correctly, -00:07:13.200 --> 00:07:19.719 -the rebase. At the same time, we want to improve Guile Elisp's +05:16.166 --> 05:18.950 +but it gets more interesting -00:07:19.720 --> 00:07:22.799 -performance to at least be competitive with ordinary Emacs +05:18.966 --> 00:05:25.000 +if we communicate the answer with an error. -00:07:22.800 --> 00:07:29.279 -Lisp. Just to characterize the performance situation, +00:05:25.100 --> 05:29.633 +or to look at a backtrace. -00:07:29.280 --> 00:07:34.479 -Guile Elisp is usually about half as fast as ordinary Elisp, +05:29.650 --> 05:32.350 +You can see here that there are -00:07:34.480 --> 00:07:37.839 -while Guile Scheme is quite often an order of magnitude +05:32.366 --> 05:35.516 +no calls to fact visible in between -00:07:37.840 --> 00:07:43.319 -faster than ordinary Elisp, and that's based on micro +05:35.533 --> 05:37.833 +the request to evaluate -00:07:43.320 --> 00:07:47.799 -benchmarks like the Gabriel benchmarks. But there's +05:37.850 --> 05:42.200 +and the error communicating the answer. -00:07:47.800 --> 00:07:52.319 -clearly a lot of room to improve our compiler's output. +05:42.200 --> 05:44.200 +That's because this tail call -00:07:52.320 --> 00:07:57.759 -If you want to mark your calendars, we're expecting to have a +05:44.200 --> 05:48.350 +has been optimized into effectively a goto. -00:07:57.760 --> 00:08:04.199 -usable version of Guile-Emacs 30 out sometime next spring. We're +05:48.366 --> 05:54.916 +This is essential for any kind -00:08:04.200 --> 00:08:06.799 -also going to put some effort into either extracting old +05:54.933 --> 00:05:59.916 +of serious functional programming. -00:08:06.800 --> 00:08:13.599 -work or doing new work that could be contributed upstream. +00:06:00.116 --> 06:03.033 +That's a peek at guile-elisp. -00:08:13.600 --> 00:08:17.559 -On the Guile side, we'll probably start out with optimizing +06:03.050 --> 06:08.066 +In 2015, I left university to go work on web technologies, -00:08:17.560 --> 00:08:22.839 -the dynamic binding facilities, which are used very seldom +06:08.083 --> 06:11.316 +and the project was dormant for a very long time. -00:08:22.840 --> 00:08:27.199 -in Scheme, but are used all the time in traditional Lisp +06:11.333 --> 06:13.433 +But that's been changing recently. -00:08:27.200 --> 00:08:31.399 -dialects. On the Emacs side, we'll be working initially on +06:13.450 --> 06:16.066 +During the last few months, -00:08:31.400 --> 00:08:35.919 -abstracting away the details of the Lisp implementation +06:16.083 --> 06:17.633 +I've been working with Larry Valkama[??] -00:08:35.920 --> 00:08:39.999 -where they're not relevant. And that will clean up the Emacs +06:17.650 --> 06:20.716 +to rebase guile-emacs -00:08:40.000 --> 00:08:44.279 -code base a bit. It'll make it easier to integrate Emacs and +06:20.733 --> 06:24.833 +onto the development branch of upstream emacs, -00:08:44.280 --> 00:08:49.919 -Guile Elisp. It will probably be helpful for anyone who +06:24.850 --> 06:29.666 +including the past decade's worth of upstream development. -00:08:49.920 --> 00:08:51.559 -is working on ordinary Elisp on their own. +06:29.683 --> 00:06:33.967 +What we've ended up with is a series of -00:08:51.560 --> 00:08:57.199 +00:06:34.267 --> 00:06:37.550 +rebases onto different versions of Emacs. + +06:37.566 --> 06:39.516 +The older ones tend to work pretty well. + +06:39.533 --> 06:46.866 +The newer ones have increasingly bad problems + +06:46.883 --> 06:49.800 +where they haven't been properly adjusted + +06:49.800 --> 06:52.200 +for changes in the Emacs implementation. + +06:52.200 --> 06:56.833 +but we do have by now a version of Emacs 30 + +06:56.850 --> 06:57.800 +which boots correctly + +06:57.800 --> 06:59.833 +and can be used for interactive debugging, + +06:59.850 --> 07:06.150 +as well as the ability to bisect the revisions of Emacs + +07:06.166 --> 07:10.516 +and find out where regressions were introduced. + +07:10.533 --> 07:14.033 +Our immediate goal is of course to complete the rebase. + +07:14.050 --> 07:16.233 +At the same time, + +07:16.250 --> 07:20.633 +we want to improve Guile Elisp's performance + +07:20.650 --> 07:24.350 +to at least be competitive with ordinary Emacs Lisp. + +07:24.366 --> 07:29.266 +Just to characterize the performance situation, + +07:29.283 --> 07:32.750 +Guile Elisp is usually about half + +07:32.766 --> 07:34.466 +as fast as ordinary Elisp, + +07:34.483 --> 07:37.833 +while Guile Scheme is quite often + +07:37.850 --> 00:07:41.250 +an order of magnitude faster than ordinary Elisp, + +00:07:41.350 --> 07:43.916 +and that's based on micro benchmarks + +07:43.933 --> 00:07:46.133 +like the Gabriel[??] benchmarks. + +00:07:46.233 --> 00:07:50.900 +but there's clearly a lot of room + +00:07:50.900 --> 00:07:53.150 +to improve our compiler's output. + +00:07:53.350 --> 07:56.633 +If you want to mark your calendars, + +07:56.650 --> 08:00.150 +we're expecting to have a usable version of Guile Emacs 30 + +08:00.166 --> 00:08:03.016 +out sometime next spring. + +00:08:03.116 --> 08:05.433 +We're also going to put some effort + +08:05.450 --> 00:08:09.000 +into either extracting old work + +00:08:09.100 --> 08:12.600 +or doing new work that could be contributed upstream. + +08:12.600 --> 00:08:16.650 +On the Guile side, we'll probably start out with + +00:08:16.750 --> 00:08:21.033 +optimizing the dynamic binding facilities, + +00:08:21.233 --> 08:23.433 +which are used very seldom in Scheme, + +08:23.450 --> 08:27.833 +but are used all the time in traditional Lisp dialects. + +08:27.850 --> 08:31.400 +On the Emacs side, we'll be working initially + +08:31.400 --> 08:35.316 +on abstracting away the details of the Lisp implementation + +08:35.333 --> 00:08:37.433 +where they're not relevant, + +00:08:37.533 --> 08:40.716 +And that will clean up the Emacs code base a bit. + +08:40.733 --> 08:45.000 +It'll make it easier to integrate Emacs and Guile Elisp. + +08:45.000 --> 08:47.916 +It will probably be helpful for anyone + +08:47.933 --> 08:51.550 +who is working on ordinary Elisp on their own. + +08:51.566 --> 08:57.200 We're also going to be adding new features to Emacs Lisp. -00:08:57.200 --> 00:09:01.639 -We've seen a few of them already. The numeric tower, tail +08:57.200 --> 08:59.316 +We've seen a few of them already. + +08:59.333 --> 09:02.633 +The new [??] tower, tail call optimization, + +09:02.650 --> 09:04.550 +common list compatibility. + +09:04.566 --> 09:07.950 +We're also going to provide access to Fibers, + +09:07.966 --> 09:12.466 +which is a guide library based on ideas from concurrent ML + +09:12.483 --> 09:15.716 +that provides much more powerful facilities + +09:15.733 --> 09:18.266 +for concurrent and parallel programming + +09:18.283 --> 00:09:24.566 +than what Emacs currently offers. + +00:09:24.666 --> 09:32.233 +This plan meets Guile Emacs' basic goals, + +09:32.250 --> 09:36.316 +and it's work that we could maybe get integrated upstream + +09:36.333 --> 00:09:38.100 +in a reasonable amount of time. + +00:09:38.200 --> 00:09:42.500 +But it's also worth considering what more we can do, + +00:09:42.600 --> 09:46.600 +and what effect Guile Emacs might have on Emacs + +09:46.600 --> 00:09:50.566 +if it becomes simply Emacs. + +00:09:50.666 --> 09:54.033 +For context, the amount of C code in Emacs + +09:54.050 --> 09:57.400 +has increased by around 50% in the last decade, + +09:57.400 --> 09:59.950 +and now it constitutes around a quarter of the code base. + +09:59.966 --> 10:06.400 +C can be a bit of a barrier + +10:06.400 --> 00:10:10.900 +to customizing and extending Emacs. + +00:10:11.000 --> 10:15.516 +For example, there are about 1500 C subroutines. + +10:15.533 --> 10:19.633 +Around 500 are used in C code, + +10:19.650 --> 10:23.150 +as well as available to Lisp code, + +10:23.166 --> 10:25.800 +and being written in C means + +10:25.800 --> 10:28.066 +that they can't be practically redefined. + +10:28.083 --> 10:34.433 +the use of C can become a barrier to extending Emacs + +10:34.450 --> 10:36.233 +or customizing its behavior. + +10:36.250 --> 10:39.200 +We might consider writing + +10:39.200 --> 00:10:42.816 +as much of Emacs as possible in Lisp. + +00:10:42.916 --> 10:46.033 +One way to speed up this process + +10:46.050 --> 10:49.400 +would be to provide a common Lisp implementation for Guile. -00:09:01.640 --> 00:09:05.919 -call optimization, Common Lisp compatibility. We're also +10:49.400 --> 10:54.833 +Note that between guile-elisp and guile-scheme, -00:09:05.920 --> 00:09:10.359 -going to provide access to Fibers, which is a Guile library +10:54.850 --> 10:57.516 +we have all of the essential ingredients -00:09:10.360 --> 00:09:14.639 -based on ideas from Concurrent ML that provides much more +10:57.533 --> 11:03.200 +for a Common Lisp environment. We can also share code -00:09:14.640 --> 00:09:17.679 -powerful facilities for concurrent and parallel +11:03.200 --> 00:11:06.016 +with other Common Lisp implementations -00:09:17.680 --> 00:09:20.679 -programming than what Emacs currently offers. +11:06.016 --> 11:10.200 +such as SBCL and SICL[??]. -00:09:20.680 --> 00:09:33.759 -This plan meets Guile-Emacs' basic goals, and it's work +11:10.200 --> 11:13.800 +Overall, the duration of the project -00:09:33.760 --> 00:09:36.879 -that we could maybe get integrated upstream in a reasonable +11:13.800 --> 11:16.916 +will be better measured in months rather than years, -00:09:36.880 --> 00:09:41.799 -amount of time. But it's also worth considering what more we +11:16.933 --> 11:19.466 +despite Common Lisp's reputation -00:09:41.800 --> 00:09:47.239 -can do, and what effect Guile-Emacs might have on Emacs if it +11:19.483 --> 00:11:21.116 +for being a large language. -00:09:47.240 --> 00:09:49.079 -becomes simply Emacs. +00:11:21.216 --> 11:24.466 +This could have multiple uses, of course. -00:09:49.080 --> 00:09:54.599 -For context, the amount of C code in Emacs has increased by +11:24.483 --> 11:29.633 +It could be a model for future improvements to Elisp, -00:09:54.600 --> 00:09:58.559 -around 50% in the last decade, and now it constitutes around +11:29.650 --> 11:34.866 +because Elisp and CL can interact directly without problems. -00:09:58.560 --> 00:10:06.399 -a quarter of the code base. C can be a bit of a barrier to +11:34.883 --> 11:38.400 +and it would be very easy for Elisp -00:10:06.400 --> 00:10:13.279 -customizing and extending Emacs. For example, there are +11:38.400 --> 11:41.466 +to borrow language features from Common Lisp. -00:10:13.280 --> 00:10:20.439 -about 1500 C subroutines. Around 500 are used in C code, as +11:41.483 --> 11:46.600 +But for the purpose of a C to Lisp transition, -00:10:20.440 --> 00:10:26.519 -well as available to Lisp code, and being written in C means +11:46.600 --> 11:50.066 +it would also provide us with instant access -00:10:26.520 --> 00:10:31.519 -that they can't be practically redefined. The use of C can +11:50.083 --> 11:52.600 +to a huge number of high-quality libraries -00:10:31.520 --> 00:10:35.839 -become a barrier to extending Emacs or customizing its +11:52.600 --> 11:54.833 +for things that -00:10:35.840 --> 00:10:40.479 -behavior. We might consider writing as much of Emacs as +11:54.850 --> 11:58.116 +Guile is not necessarily equipped to deal with, -00:10:40.480 --> 00:10:46.039 -possible in Lisp. One way to speed up this process would +11:58.133 --> 12:01.350 +such as access to low-level Windows APIs, -00:10:46.040 --> 00:10:52.199 -be to provide a Common Lisp implementation for Guile. Note +12:01.366 --> 12:05.150 +as well as lots of other libraries, -00:10:52.200 --> 00:10:56.199 -that between Guile Elisp and Guile Scheme, we have all of +12:05.166 --> 12:10.000 +such as interfaces to GUI toolkits -00:10:56.200 --> 00:10:58.839 -the essential ingredients for a Common Lisp environment. +12:10.000 --> 00:12:13.766 +for a variety of operating systems. -00:10:58.840 --> 00:11:03.279 -We can also share code with other Common Lisp +00:12:13.866 --> 12:20.550 +At a certain point, this has technical advantages. -00:11:03.280 --> 00:11:12.479 -implementations such as SBCL and SICL. Overall, the +12:20.566 --> 00:12:24.216 +If most of Emacs is written in Lisp, -00:11:12.480 --> 00:11:15.959 -duration of the project will be better measured in months +00:12:24.216 --> 12:27.233 +then we could consider using Guile Hoot -00:11:15.960 --> 00:11:19.479 -rather than years, despite Common Lisp's reputation for +12:27.250 --> 12:29.666 +to compile Emacs to WebAssembly, -00:11:19.480 --> 00:11:23.959 -being a large language. This could have multiple uses, of +12:29.683 --> 12:33.200 +making it available perhaps in web browsers -00:11:23.960 --> 00:11:29.199 -course. It could be a model for future improvements to +12:33.200 --> 12:37.233 +or on systems with the WebAssembly system interface. -00:11:29.200 --> 00:11:38.399 -Elisp, because Elisp and CL can interact directly without +12:37.250 --> 12:41.266 +But it would also be a great victory -00:11:38.400 --> 00:11:41.319 -problems. And it would be very easy for Elisp to borrow +12:41.283 --> 12:43.033 +for practical software freedom. -00:11:41.320 --> 00:11:45.479 -language features from Common Lisp. But for the purpose of a +12:43.050 --> 12:45.866 +That's the idea that freedom one, -00:11:45.480 --> 00:11:49.559 -C to Lisp transition, it would also provide us with instant +12:45.883 --> 12:48.350 +the freedom to study and modify programs, -00:11:49.560 --> 00:11:52.599 -access to a huge number of high-quality libraries for +12:48.366 --> 12:51.633 +should not just be legally and technically possible, -00:11:52.600 --> 00:11:58.159 -things that Guile is not necessarily equipped to deal with, +12:51.650 --> 12:53.316 +but should be actively encouraged -00:11:58.160 --> 00:12:03.879 -such as access to low-level Windows APIs, as well as lots of +12:53.333 --> 12:57.066 +by our competing environments. -00:12:03.880 --> 00:12:08.799 -other libraries, such as interfaces to GUI toolkits for a +12:57.083 --> 13:00.116 +Emacs is really one of the archetypal examples of this, -00:12:08.800 --> 00:12:12.079 -variety of operating systems. +13:00.133 --> 00:13:03.116 +but we can and should go further. -00:12:12.080 --> 00:12:21.799 -At a certain point, this has technical advantages. If +00:13:03.216 --> 13:08.400 +When Emacs is implemented primarily in Lisp, -00:12:21.800 --> 00:12:26.119 -most of Emacs is written in Lisp, then we could consider +13:08.400 --> 13:11.466 +the entirety of the system -00:12:26.120 --> 00:12:30.759 -using Guile Hoot to compile Emacs to WebAssembly, making it +13:11.483 --> 13:14.600 +will be transparent to examination -00:12:30.760 --> 00:12:35.159 -available perhaps in web browsers or on systems with the +13:14.600 --> 13:16.066 +and open to modification. -00:12:35.160 --> 00:12:40.679 -WebAssembly System Interface. But it would also be a great +13:16.083 --> 13:21.200 +Every part of Emacs will be instantaneously inspectable, -00:12:40.680 --> 00:12:44.759 -victory for practical software freedom. That's the idea +13:21.200 --> 00:13:24.916 +redefinable, and debuggable. -00:12:44.760 --> 00:12:48.359 -that Freedom One, the freedom to study and modify programs, +00:13:25.016 --> 13:28.266 +This will be a fundamental change -00:12:48.360 --> 00:12:52.039 -should not just be legally and technically possible, but +13:28.283 --> 13:32.800 +in what is possible to do with Emacs extensions. -00:12:52.040 --> 00:12:54.719 -should be actively encouraged by our computing +13:32.800 --> 13:37.000 +For example, one experiment I'd be interested in -00:12:54.720 --> 00:12:58.959 -environments. Emacs is really one of the archetypal +13:37.000 --> 13:40.316 +is using the Common Lisp Interface Manager -00:12:58.960 --> 00:13:02.519 -examples of this, but we can and should go further. +13:40.333 --> 13:43.233 +as the basis for Emacs's user interface. -00:13:02.520 --> 00:13:10.919 -When Emacs is implemented primarily in Lisp, the entirety +13:43.250 --> 13:48.516 +Screwlisp is giving a talk about McCLIM later today, -00:13:10.920 --> 00:13:14.599 -of the system will be transparent to examination and open to +13:48.533 --> 13:53.233 +but for present purposes, -00:13:14.600 --> 00:13:20.359 -modification. Every part of Emacs will be instantaneously +13:53.250 --> 13:55.633 +just think of it as a super-powered version -00:13:20.360 --> 00:13:23.319 -inspectable, redefinable, and debuggable. +13:55.650 --> 13:58.350 +of Emacs's concept of interactive functions. -00:13:23.320 --> 00:13:30.559 -This will be a fundamental change in what is possible to +13:58.366 --> 14:02.800 +It would be a pretty long-term project -00:13:30.560 --> 00:13:36.159 -do with Emacs extensions. For example, one experiment I'd +14:02.800 --> 14:04.800 +in Emacs as it currently exists, -00:13:36.160 --> 00:13:40.319 -be interested in is using the Common Lisp Interface Manager +14:04.800 --> 14:06.600 +but it would be almost trivial -00:13:40.320 --> 00:13:46.479 -as the basis for Emacs's user interface. Screwlisp is +14:06.600 --> 14:12.633 +if Emacs were customizable at the lowest layers via Lisp. -00:13:46.480 --> 00:13:52.879 -giving a talk about McCLIM later today, but for present +14:12.650 --> 14:19.150 +We'll certainly be looking at the practicality -00:13:52.880 --> 00:13:55.919 -purposes, just think of it as a super-powered version of +14:19.166 --> 14:20.950 +of these kinds of changes -00:13:55.920 --> 00:14:01.279 -Emacs's concept of interactive functions. It would be a +14:20.966 --> 00:14:25.033 +as we continue developing Guile Emacs. -00:14:01.280 --> 00:14:04.799 -pretty long-term project in Emacs as it currently exists, +00:14:25.133 --> 00:14:29.933 +Finally, how can you get involved -00:14:04.800 --> 00:14:10.519 -but it would be almost trivial if Emacs were customizable at +00:14:30.033 --> 00:14:32.400 +with and support Guile Emacs? -00:14:10.520 --> 00:14:11.599 -the lowest layers via Lisp. +00:14:32.500 --> 14:35.316 +One way to help is just by trying it out -00:14:11.600 --> 00:14:19.599 -We'll certainly be looking at the practicality of these +14:35.333 --> 00:14:37.716 +and letting us know what your experiences are like. -00:14:19.600 --> 00:14:23.839 -kinds of changes as we continue developing Guile-Emacs. +00:14:37.816 --> 14:41.466 +There will be a snapshot available -00:14:23.840 --> 00:14:31.719 -Finally, how can you get involved with and support Guile +14:41.483 --> 00:14:44.166 +on the Codeberg project site -00:14:31.720 --> 00:14:35.999 -Emacs? One way to help is just by trying it out and letting us +00:14:44.266 --> 14:47.000 +of the version that I'm using to give this presentation. -00:14:36.000 --> 00:14:40.519 -know what your experiences are like. There will be a +14:47.000 --> 14:51.116 +It will be available both as a Guix package -00:14:40.520 --> 00:14:44.079 -snapshot available on the Codeberg project site of the +14:51.133 --> 14:55.916 +and as a portable tarball. This will be more interesting -00:14:44.080 --> 00:14:48.759 -version that I'm using to give this presentation. It will be +14:55.933 --> 00:15:00.266 +as we get closer to a complete rebase. -00:14:48.760 --> 00:14:52.719 -available both as a Guix package and as a portable tarball. +00:15:00.366 --> 15:06.516 +We're also always happy to talk to potential contributors -00:14:52.720 --> 00:14:58.799 -This will be more interesting as we get closer to a complete +15:06.533 --> 00:15:12.100 +or potential collaborators from other projects. -00:14:58.800 --> 00:15:05.479 -rebase. We're also always happy to talk to potential +00:15:12.200 --> 15:16.433 +We can always use bug reports, -00:15:05.480 --> 00:15:10.879 -contributors or potential collaborators from other +15:16.450 --> 15:18.866 +and we're interested in what kind of features -00:15:10.880 --> 00:15:11.599 -projects. +15:18.883 --> 15:21.716 +people actually want to see in Guile Emacs. -00:15:11.600 --> 00:15:18.159 -We can always use bug reports, and we're interested in what +15:21.733 --> 00:15:25.200 +Guile Emacs is also being developed -00:15:18.160 --> 00:15:21.719 -kind of features people actually want to see in Guile-Emacs. +00:15:25.300 --> 00:15:27.816 +by a small worker cooperative, -00:15:21.720 --> 00:15:27.359 -Guile-Emacs is also being developed by a small worker +00:15:27.916 --> 00:15:33.100 +so donations are a pretty direct way to support the project. -00:15:27.360 --> 00:15:32.159 -cooperative, so donations are a pretty direct way to +00:15:33.200 --> 15:37.150 +If you do nothing else, I recommend going to the website -00:15:32.160 --> 00:15:36.039 -support the project. If you do nothing else, I recommend +15:37.166 --> 15:40.716 +and subscribing to our mailing lists -00:15:36.040 --> 00:15:40.719 -going to the website and subscribing to our mailing lists so +15:40.733 --> 15:45.600 +so that you can keep up with news on the project. -00:15:40.720 --> 00:15:45.879 -that you can keep up with news on the project. If you're +15:45.600 --> 15:47.316 +If you're watching this at Emacsconf, -00:15:45.880 --> 00:15:49.239 -watching this at EmacsConf, there will be a Q&A session +15:47.333 --> 15:50.466 +there will be a Q&A session immediately following this, -00:15:49.240 --> 00:15:57.080 -immediately following this, and thanks for watching! +15:50.483 --> 15:57.066 +and thanks for watching. |