Automated commit

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.