-Hello everyone. I'm Robin Templeton, and I'm going to talk +00:00.000 --> 00:03.066 +Hello everyone, I'm Robin Templeton,
-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
-project. +00:05.766 --> 00:13.866 +and recent progress on the Guile Emacs project.
-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,
-implementation of the Scheme programming language, which +00:16.450 --> 00:19.716 +it's an implementation of the Scheme programming language,
-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,
-Guile is GNU's official extension language. The goal of +00:22.166 --> 00:24.550 +and in the same family as Emacs Lisp,
-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.
-Emacs's Lisp support. It has two main components: a new +00:28.166 --> 00:30.400 +The goal of the Guile Emacs project
-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.
-Emacs in which the built-in Lisp implementation is +00:34.966 --> 00:37.116 +It has two main components:
-entirely replaced with Guile Elisp. We expect the +00:37.133 --> 00:41.033 +a new Emacs Lisp compiler built on top of Guile,
-combination of these two projects to have several +00:41.050 --> 00:42.550 +and a variant of Emacs
-benefits. One is improved performance. Another is +00:42.566 --> 00:45.316 +in which the built-in Lisp implementation
-increased expressiveness for Elisp and making it easier to +00:45.333 --> 00:49.716 +is entirely replaced with Guile Elisp.
-extend and experiment with the language. Finally, it +00:49.733 --> 00:52.800 +We expect the combination of these two projects
-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.
-be responsible for the language implementation, so Emacs +00:57.366 --> 01:00.200 +Another is increased expressiveness for Elisp
-will no longer have to include a Lisp interpreter. It +01:00.200 --> 01:04.350 +and making it easier to extend
-will also become possible to implement much more of Emacs in +01:04.366 --> 01:07.200 +and experiment with the language.
-Lisp than is currently feasible. Of course, this raises +01:07.200 --> 01:08.550 +Finally, it will reduce
-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.
-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,
-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.
-multiple languages using its compiler tower. To add +01:21.366 --> 01:23.200 +It will also become possible
-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
-compiler from the source language to Tree-IL, which is +01:25.683 --> 01:29.233 +than is currently feasible.
-essentially a low-level, minimal representation of +01:29.250 --> 01:31.116 +Of course, this raises the question of
-Scheme. All of Guile's compiler optimizations occur at the +01:31.133 --> 01:34.033 +why Guile is suitable for this product.
-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.
-lower-level details of the compiler when initially +01:36.683 --> 01:39.400 +Guile is primarily a Scheme implementation,
-implementing your language. Guile also has some Lisp +01:39.400 --> 01:42.150 +but it also has built-in support for multiple languages
-features that are very rare in Scheme implementations. For +01:42.166 --> 01:43.466 +using its compiler tower.
-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,
-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
-the Common Lisp Object System and its metaobject protocol, +01:50.083 --> 01:52.550 +from the source language to TRIAL[??],
-which is called GOOPS. +01:52.566 --> 01:55.800 +which is essentially a low-level,
-The idea of Guile-Emacs has a pretty long history, going back +01:55.800 --> 01:58.866 +minimal representation of Scheme.
-at least three decades. There have been about half a dozen +01:58.883 --> 02:01.800 +All of Guile's compiler optimizations
-previous implementation attempts. But the current +02:01.800 --> 02:04.433 +occur at the TRIAL[??] layer or lower,
-iteration began with a series of six Summer of Code +02:04.450 --> 02:06.033 +so you don't need to worry
-internships: Daniel Kraft's in 2009, and then my +02:06.050 --> 02:09.633 +about the lower-level details of the compiler
-internships from 2010 to 2014. My basic implementation +02:09.650 --> 02:12.350 +when initially implementing your language.
-strategy was pretty straightforward. I implemented a core +02:12.366 --> 02:14.633 +Guile also has some Lisp features
-subset of Elisp, which was enough to run some batch mode +02:14.650 --> 02:18.316 +that are very rare in schema implementations.
-programs outside of Emacs. In Emacs, I modified the garbage +02:18.333 --> 02:20.033 +For example, it has a nil value
-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,
-their libguile equivalents. I replaced Emacs' Lisp +02:23.933 --> 02:25.633 +just like an Elisp,
-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
-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.
-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.
-Guile-Emacs. It used Guile Elisp alone as its Lisp +02:40.166 --> 02:43.866 +going back at least three decades.
-implementation and was completely compatible with Emacs +02:43.883 --> 02:44.550 +There have been about
-functionality and with external extensions. One caveat +02:44.566 --> 02:48.000 +half a dozen previous implementation attempts.
-was that performance was pretty bad, because I was focused +02:48.000 --> 02:49.950 +But the current iteration began with
-on correctness, as well as ease of integration with the +02:49.966 --> 02:52.866 +a series of six Summer of Code internships,
-Emacs C code. But it was nonetheless a major milestone for +02:52.883 --> 02:56.033 +Daniel Kraft's[??] in 2009,
-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.
-Guile-Elisp. +03:01.200 --> 03:03.000 +My basic implementation strategy
-For starters, we have access to Guile modules. If we call +03:03.000 --> 03:05.316 +was pretty straightforward.
-Guile's version function, we can see that we're running +03:05.333 --> 03:07.466 +I implemented a core subset of Elisp,
-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
-the arithmetic functions. We also have multiple values. We +03:10.400 --> 03:12.833 +outside of Emacs.
-have to be careful to use Guile's values procedure here, not +03:12.850 --> 03:15.266 +In Emacs, I modified the garbage collector
-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
-rather than being an emulation. Finally, we have tail +03:18.600 --> 03:23.033 +to use their libgal equivalents.
-call elimination. Naturally, we're going to use factorial +03:23.050 --> 03:26.950 +I replaced Emacs' Lisp evaluator
-to demonstrate it. If n is zero, return the answer, else +03:26.966 --> 03:32.200 +with the one provided by guile-elisp.[??]
-recurse with n less one and n times a. +03:32.200 --> 03:34.033 +After a little over a year of work
-Of course, this definition works correctly, but it gets +03:34.050 --> 03:37.950 +at the end of the 2014 internship,
-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.
-error, +03:44.333 --> 03:48.916 +It used Guile Elisp alone as its Lisp implementation
-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
-calls to fact visible in between the request to evaluate and +03:53.933 --> 03:56.716 +and with external extensions.
-the error communicating the answer. That's because +03:56.733 --> 03:59.433 +One caveat was that performance was pretty bad,
-this tail call has been optimized into effectively a goto. +03:59.450 --> 04:03.033 +because I was focused on correctness,
-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.
-programming. +04:07.600 --> 04:11.550 +But it was nonetheless a major milestone for the project.
-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.
-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.
-for a very long time. But that's been changing recently. +04:23.250 --> 04:25.116 +If we call guile's version function,
-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,
-Valkama to rebase Guile-Emacs onto the development branch +04:30.533 --> 04:33.233 +have access to some of the numeric tower
-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.
-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,
-of rebases onto different versions of Emacs. The older ones +04:43.966 --> 04:46.666 +not the CL libraries,
-tend to work pretty well. The newer ones have increasingly +04:46.683 --> 04:48.833 +but you can see that this works properly
-bad problems where they haven't been properly adjusted for +04:48.850 --> 04:51.550 +rather than being an emulation.
-changes in the Emacs implementation. But we do have by now a +04:51.566 --> 04:54.033 +Finally, we have tail call elimination.
-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.
-interactive debugging, as well as the ability to bisect the +05:02.883 --> 05:05.633 +If n is zero, return the answer,
-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.
-introduced. Our immediate goal is of course to complete +05:14.283 --> 05:16.150 +Of course this definition works correctly,
-the rebase. At the same time, we want to improve Guile Elisp's +05:16.166 --> 05:18.950 +but it gets more interesting
-performance to at least be competitive with ordinary Emacs +05:18.966 --> 00:05:25.000 +if we communicate the answer with an error.
-Lisp. Just to characterize the performance situation, +00:05:25.100 --> 05:29.633 +or to look at a backtrace.
-Guile Elisp is usually about half as fast as ordinary Elisp, +05:29.650 --> 05:32.350 +You can see here that there are
-while Guile Scheme is quite often an order of magnitude +05:32.366 --> 05:35.516 +no calls to fact visible in between
-faster than ordinary Elisp, and that's based on micro +05:35.533 --> 05:37.833 +the request to evaluate
-benchmarks like the Gabriel benchmarks. But there's +05:37.850 --> 05:42.200 +and the error communicating the answer.
-clearly a lot of room to improve our compiler's output. +05:42.200 --> 05:44.200 +That's because this tail call
-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.
-usable version of Guile-Emacs 30 out sometime next spring. We're +05:48.366 --> 05:54.916 +This is essential for any kind
-also going to put some effort into either extracting old +05:54.933 --> 00:05:59.916 +of serious functional programming.
-work or doing new work that could be contributed upstream. +00:06:00.116 --> 06:03.033 +That's a peek at guile-elisp.
-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,
-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.
-in Scheme, but are used all the time in traditional Lisp +06:11.333 --> 06:13.433 +But that's been changing recently.
-dialects. On the Emacs side, we'll be working initially on +06:13.450 --> 06:16.066 +During the last few months,
-abstracting away the details of the Lisp implementation +06:16.083 --> 06:17.633 +I've been working with Larry Valkama[??]
-where they're not relevant. And that will clean up the Emacs +06:17.650 --> 06:20.716 +to rebase guile-emacs
-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,
-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.
-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: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.
-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.
-call optimization, Common Lisp compatibility. We're also +10:49.400 --> 10:54.833 +Note that between guile-elisp and guile-scheme,
-going to provide access to Fibers, which is a Guile library +10:54.850 --> 10:57.516 +we have all of the essential ingredients
-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
-powerful facilities for concurrent and parallel +11:03.200 --> 00:11:06.016 +with other Common Lisp implementations
-programming than what Emacs currently offers. +11:06.016 --> 11:10.200 +such as SBCL and SICL[??].
-This plan meets Guile-Emacs' basic goals, and it's work +11:10.200 --> 11:13.800 +Overall, the duration of the project
-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,
-amount of time. But it's also worth considering what more we +11:16.933 --> 11:19.466 +despite Common Lisp's reputation
-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.
-becomes simply Emacs. +00:11:21.216 --> 11:24.466 +This could have multiple uses, of course.
-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,
-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.
-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
-customizing and extending Emacs. For example, there are +11:38.400 --> 11:41.466 +to borrow language features from Common Lisp.
-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,
-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
-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
-become a barrier to extending Emacs or customizing its +11:52.600 --> 11:54.833 +for things that
-behavior. We might consider writing as much of Emacs as +11:54.850 --> 11:58.116 +Guile is not necessarily equipped to deal with,
-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,
-be to provide a Common Lisp implementation for Guile. Note +12:01.366 --> 12:05.150 +as well as lots of other libraries,
-that between Guile Elisp and Guile Scheme, we have all of +12:05.166 --> 12:10.000 +such as interfaces to GUI toolkits
-the essential ingredients for a Common Lisp environment. +12:10.000 --> 00:12:13.766 +for a variety of operating systems.
-We can also share code with other Common Lisp +00:12:13.866 --> 12:20.550 +At a certain point, this has technical advantages.
-implementations such as SBCL and SICL. Overall, the +12:20.566 --> 00:12:24.216 +If most of Emacs is written in Lisp,
-duration of the project will be better measured in months +00:12:24.216 --> 12:27.233 +then we could consider using Guile Hoot
-rather than years, despite Common Lisp's reputation for +12:27.250 --> 12:29.666 +to compile Emacs to WebAssembly,
-being a large language. This could have multiple uses, of +12:29.683 --> 12:33.200 +making it available perhaps in web browsers
-course. It could be a model for future improvements to +12:33.200 --> 12:37.233 +or on systems with the WebAssembly system interface.
-Elisp, because Elisp and CL can interact directly without +12:37.250 --> 12:41.266 +But it would also be a great victory
-problems. And it would be very easy for Elisp to borrow +12:41.283 --> 12:43.033 +for practical software freedom.
-language features from Common Lisp. But for the purpose of a +12:43.050 --> 12:45.866 +That's the idea that freedom one,
-C to Lisp transition, it would also provide us with instant +12:45.883 --> 12:48.350 +the freedom to study and modify programs,
-access to a huge number of high-quality libraries for +12:48.366 --> 12:51.633 +should not just be legally and technically possible,
-things that Guile is not necessarily equipped to deal with, +12:51.650 --> 12:53.316 +but should be actively encouraged
-such as access to low-level Windows APIs, as well as lots of +12:53.333 --> 12:57.066 +by our competing environments.
-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,
-variety of operating systems. +13:00.133 --> 00:13:03.116 +but we can and should go further.
-At a certain point, this has technical advantages. If +00:13:03.216 --> 13:08.400 +When Emacs is implemented primarily in Lisp,
-most of Emacs is written in Lisp, then we could consider +13:08.400 --> 13:11.466 +the entirety of the system
-using Guile Hoot to compile Emacs to WebAssembly, making it +13:11.483 --> 13:14.600 +will be transparent to examination
-available perhaps in web browsers or on systems with the +13:14.600 --> 13:16.066 +and open to modification.
-WebAssembly System Interface. But it would also be a great +13:16.083 --> 13:21.200 +Every part of Emacs will be instantaneously inspectable,
-victory for practical software freedom. That's the idea +13:21.200 --> 00:13:24.916 +redefinable, and debuggable.
-that Freedom One, the freedom to study and modify programs, +00:13:25.016 --> 13:28.266 +This will be a fundamental change
-should not just be legally and technically possible, but +13:28.283 --> 13:32.800 +in what is possible to do with Emacs extensions.
-should be actively encouraged by our computing +13:32.800 --> 13:37.000 +For example, one experiment I'd be interested in
-environments. Emacs is really one of the archetypal +13:37.000 --> 13:40.316 +is using the Common Lisp Interface Manager
-examples of this, but we can and should go further. +13:40.333 --> 13:43.233 +as the basis for Emacs's user interface.
-When Emacs is implemented primarily in Lisp, the entirety +13:43.250 --> 13:48.516 +Screwlisp is giving a talk about McCLIM later today,
-of the system will be transparent to examination and open to +13:48.533 --> 13:53.233 +but for present purposes,
-modification. Every part of Emacs will be instantaneously +13:53.250 --> 13:55.633 +just think of it as a super-powered version
-inspectable, redefinable, and debuggable. +13:55.650 --> 13:58.350 +of Emacs's concept of interactive functions.
-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
-do with Emacs extensions. For example, one experiment I'd +14:02.800 --> 14:04.800 +in Emacs as it currently exists,
-be interested in is using the Common Lisp Interface Manager +14:04.800 --> 14:06.600 +but it would be almost trivial
-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.
-giving a talk about McCLIM later today, but for present +14:12.650 --> 14:19.150 +We'll certainly be looking at the practicality
-purposes, just think of it as a super-powered version of +14:19.166 --> 14:20.950 +of these kinds of changes
-Emacs's concept of interactive functions. It would be a +14:20.966 --> 00:14:25.033 +as we continue developing Guile Emacs.
-pretty long-term project in Emacs as it currently exists, +00:14:25.133 --> 00:14:29.933 +Finally, how can you get involved
-but it would be almost trivial if Emacs were customizable at +00:14:30.033 --> 00:14:32.400 +with and support Guile Emacs?
-the lowest layers via Lisp. +00:14:32.500 --> 14:35.316 +One way to help is just by trying it out
-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.
-kinds of changes as we continue developing Guile-Emacs. +00:14:37.816 --> 14:41.466 +There will be a snapshot available
-Finally, how can you get involved with and support Guile +14:41.483 --> 00:14:44.166 +on the Codeberg project site
-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.
-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
-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
-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.
-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
-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.
-rebase. We're also always happy to talk to potential +00:15:12.200 --> 15:16.433 +We can always use bug reports,
-contributors or potential collaborators from other +15:16.450 --> 15:18.866 +and we're interested in what kind of features
-projects. +15:18.883 --> 15:21.716 +people actually want to see in Guile Emacs.
-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
-kind of features people actually want to see in Guile-Emacs. +00:15:25.300 --> 00:15:27.816 +by a small worker cooperative,
-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.
-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
-support the project. If you do nothing else, I recommend +15:37.166 --> 15:40.716 +and subscribing to our mailing lists
-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.
-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,
-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,
-immediately following this, and thanks for watching! +15:50.483 --> 15:57.066 +and thanks for watching. -- cgit v1.2.3