add YouTube URLs, Q&A video URLsHEADmaster

4 files changed, 596 insertions, 595 deletions

diff --git a/2024/captions/emacsconf-2024-color--colour-your-emacs-with-ease--ryota--answers.vtt b/2024/captions/emacsconf-2024-color--colour-your-emacs-with-ease--ryota--answers.vtt
index b27008a3..3266d254 100644
--- a/2024/captions/emacsconf-2024-color--colour-your-emacs-with-ease--ryota--answers.vtt
+++ b/2024/captions/emacsconf-2024-color--colour-your-emacs-with-ease--ryota--answers.vtt
@@ -1,747 +1,748 @@
 WEBVTT
 
-00:00.169 --> 00:01.830
+00:00:00.000 --> 00:00:06.039
 ... Org mode and kind of note taking. And that meant that it wasn't
 
-00:02.810 --> 00:08.532
+00:00:06.040 --> 00:00:10.679
 too difficult to get started with. But when I started more on
 
-00:08.972 --> 00:15.474
+00:00:10.680 --> 00:00:14.959
 the coding side, because I'm a software engineer, you know,
 
-00:08.972 --> 00:15.474
+00:00:14.960 --> 00:00:20.679
 on the day job. That kind of got me to think that the colors and
 
-00:16.366 --> 00:24.790
+00:00:20.680 --> 00:00:26.479
 how themes look, how Emacs looks, was affecting. And that's
 
-00:25.331 --> 00:28.973
+00:00:26.480 --> 00:00:30.719
 how it kind of came to picture. So I could have kind of gone
 
-00:29.073 --> 00:36.917
+00:00:30.720 --> 00:00:34.919
 into a little bit more coding side of things, but I didn't
 
-00:29.073 --> 00:36.917
+00:00:34.920 --> 00:00:38.319
 want to stress too much on the talk. So that's why I kind of
 
-00:36.957 --> 00:41.919
+00:00:38.320 --> 00:00:43.439
 stuck to a very small bits of Org Mode and Elisp. And yeah, I
 
-00:42.319 --> 00:45.321
+00:00:43.440 --> 00:00:48.159
 think that's how it came about. Yeah, but that's perfectly
 
-00:46.536 --> 00:48.577
+00:00:48.160 --> 00:00:52.119
 fine. That's one of the chief reasons why we have two tracks
 
-00:49.437 --> 00:52.778
+00:00:52.120 --> 00:00:54.799
 for Emacs content. We've had those for the last four years, I
 
-00:52.798 --> 00:55.059
+00:00:54.800 --> 00:00:57.279
 think. It's because we have a general track, which is more
 
-00:55.119 --> 01:05.442
+00:00:57.280 --> 00:00:59.239
 geared towards people who want a general... well,
 
-00:55.119 --> 01:05.442
+00:00:59.240 --> 00:01:01.799
 generally people who are highly interested into org mode
 
-00:55.119 --> 01:05.442
+00:01:01.800 --> 00:01:03.999
 and not necessarily into coding, but just to whet their
 
-00:55.119 --> 01:05.442
+00:01:04.000 --> 00:01:08.399
 appetite to what can be done. And on the DevTrack, we have,
 
-01:06.082 --> 01:12.986
+00:01:08.400 --> 00:01:11.519
 well, this year we have talked about Rust and about other
 
-01:06.082 --> 01:12.986
+00:01:11.520 --> 00:01:13.559
 fancy things that people can do with Emacs. But, you know,
 
-01:13.006 --> 01:15.768
+00:01:13.560 --> 00:01:15.559
 I'm also a software engineer, you know, we do this all the
 
-01:13.006 --> 01:15.768
+00:01:15.560 --> 00:01:18.079
 time. Sometimes it's just fine to just chat about colors and
 
-01:15.808 --> 01:21.751
+00:01:18.080 --> 00:01:20.959
 just the results of what we develop rather than how the
 
-01:15.808 --> 01:21.751
+00:01:20.960 --> 00:01:24.839
 sausage is made. So that's completely fine too. I'm not sure
 
 NOTE Why colour?
 
-01:23.733 --> 01:32.618
+00:01:24.840 --> 00:01:28.879
 if you mentioned it in your presentation, but why color, out
 
-01:23.733 --> 01:32.618
+00:01:28.880 --> 00:01:31.479
 of all the things you could be ricing on your setup, why were
 
-01:23.733 --> 01:32.618
+00:01:31.480 --> 00:01:37.559
 you so interested about colors? I think it was just that
 
-01:34.870 --> 01:41.176
+00:01:37.560 --> 00:01:40.239
 mainly that I had to do a lot of context switch between
 
-01:34.870 --> 01:41.176
+00:01:40.240 --> 00:01:44.119
 different languages. Elisp is not the one because Elisp is
 
-01:41.576 --> 01:46.600
+00:01:44.120 --> 00:01:48.079
 something that I would do for Emacs editing. But for day job,
 
-01:47.061 --> 01:52.385
+00:01:48.080 --> 00:01:52.999
 I had to use mainly Go as I work with Kubernetes quite a bit. So
 
-01:52.525 --> 01:57.109
+00:01:53.000 --> 00:01:58.119
 Go and also web languages like TypeScript, JavaScript, you
 
-01:58.090 --> 02:13.642
+00:01:58.120 --> 00:02:01.519
 know, those languages, where I felt that whenever I was
 
-01:58.090 --> 02:13.642
+00:02:01.520 --> 00:02:05.359
 switching context to a different language, I felt that it's
 
-01:58.090 --> 02:13.642
+00:02:05.360 --> 00:02:08.839
 kind of annoying to see all the different colors in
 
-01:58.090 --> 02:13.642
+00:02:08.840 --> 00:02:11.999
 languages like TypeScript, where, you know, VS Code way
 
-01:58.090 --> 02:13.642
+00:02:12.000 --> 00:02:15.799
 would be very full of colors. which I felt that, okay, like,
 
-02:14.262 --> 02:23.569
+00:02:15.800 --> 00:02:18.759
 why do I have to have that many different colors on let and
 
-02:14.262 --> 02:23.569
+00:02:18.760 --> 00:02:23.759
 constant or the keywords where it could be just a white text?
 
-02:23.789 --> 02:25.170
+00:02:23.760 --> 00:02:27.679
 It didn't have to be that colorful. So that was the bit, the
 
-02:25.890 --> 02:30.373
+00:02:27.680 --> 00:02:31.399
 most annoying bit when it came to context switching. And I
 
-02:30.974 --> 02:35.197
+00:02:31.400 --> 00:02:34.759
 felt that that just didn't happen in the Org Mode or writing
 
-02:30.974 --> 02:35.197
+00:02:34.760 --> 00:02:40.799
 in general. So I had to find a way to make it work, make more
 
-02:36.017 --> 02:41.481
+00:02:40.800 --> 00:02:46.199
 coding make my coding more kind of friendly to me and that's
 
-02:42.173 --> 02:59.576
+00:02:46.200 --> 00:02:50.039
 when I thought maybe just the colors are something that's
 
-02:42.173 --> 02:59.576
+00:02:50.040 --> 00:02:54.039
 bothering me and it actually was the case and that's how I got
 
-02:42.173 --> 02:59.576
+00:02:54.040 --> 00:02:59.359
 to more into the color kind of journey and got too much into it
 
-02:42.173 --> 02:59.576
+00:02:59.360 --> 00:03:04.039
 I guess. Right, and was it what eventually motivated you to
 
 NOTE What motivated you to learn Elisp and get into the Emacs core?
 
-03:00.535 --> 03:05.778
+00:03:04.040 --> 00:03:06.999
 learn Elisp and to get into the Emacs core? Because it's
 
-03:05.798 --> 03:22.406
+00:03:07.000 --> 00:03:09.399
 funny how you find plenty of people using Emacs in Org Mode
 
-03:05.798 --> 03:22.406
+00:03:09.400 --> 00:03:11.399
 and then they find something that they take particular
 
-03:05.798 --> 03:22.406
+00:03:11.400 --> 00:03:15.039
 issue with, for you it's the color, and then they just go all
 
-03:05.798 --> 03:22.406
+00:03:15.040 --> 00:03:18.039
 in trying to pull the rope as far as they can to try to
 
-03:05.798 --> 03:22.406
+00:03:18.040 --> 00:03:21.359
 understand as much as possible about what code is managing
 
-03:05.798 --> 03:22.406
+00:03:21.360 --> 00:03:23.879
 this part of the application. Like for you it was color, for
 
-03:22.786 --> 03:25.047
+00:03:23.880 --> 00:03:27.999
 me it was the org agenda, I desperately wanted to make Org
 
-03:25.367 --> 03:30.692
+00:03:28.000 --> 00:03:32.439
 Agenda do something that it wasn't able to do. And five
 
-03:31.433 --> 03:36.318
+00:03:32.440 --> 00:03:35.199
 years, well, actually, no, 10 years later, I find myself
 
-03:31.433 --> 03:36.318
+00:03:35.200 --> 00:03:38.199
 hosting Emacs Cons. So, you never know just how far you're
 
-03:36.598 --> 03:39.201
+00:03:38.200 --> 00:03:40.399
 going to be pulling this rope. So, it's really interesting
 
-03:39.561 --> 03:42.224
+00:03:40.400 --> 00:03:44.679
 for me that my call was this. But back to the question, is this
 
-03:42.464 --> 03:48.150
+00:03:44.680 --> 00:03:47.759
 what eventually motivated you to get into Elisp and the core
 
-03:42.464 --> 03:48.150
+00:03:47.760 --> 00:03:53.439
 of Emacs? I think that the original journey to move to Emacs
 
-03:49.798 --> 04:02.250
+00:03:53.440 --> 00:03:56.959
 was around keybindings that I got annoyed with with other
 
-03:49.798 --> 04:02.250
+00:03:56.960 --> 00:03:59.839
 solutions, not just, you know, not speaking of Emacs
 
-03:49.798 --> 04:02.250
+00:03:59.840 --> 00:04:02.879
 keybinding or anything, like anything in general. The main
 
-04:02.870 --> 04:09.797
+00:04:02.880 --> 00:04:07.519
 reason was that I used Dovrak keyboard layout, and that
 
-04:02.870 --> 04:09.797
+00:04:07.520 --> 00:04:10.799
 meant that all the C-c, C-v, C-p, whatever, It just is
 
-04:10.257 --> 04:11.417
+00:04:10.800 --> 00:04:13.919
 all over the place. So I had to find something that could work
 
-04:11.577 --> 04:14.298
+00:04:13.920 --> 00:04:17.039
 for me. And Emacs was a solution that allowed me to do
 
-04:14.898 --> 04:17.499
+00:04:17.040 --> 00:04:20.479
 anything. And that's the kind of the journey that it
 
-04:18.019 --> 04:21.519
+00:04:20.480 --> 00:04:24.039
 originally started. And from there, started tweaking org
 
-04:21.599 --> 04:28.421
+00:04:24.040 --> 00:04:28.439
 mode and writing experience to be tuned to my liking. Color
 
-04:29.101 --> 04:33.682
+00:04:28.440 --> 00:04:32.559
 was another thing that I thought, OK, maybe I could do it
 
-04:29.101 --> 04:33.682
+00:04:32.560 --> 00:04:36.239
 easily with org mode. And when I started to use more of the
 
-04:34.262 --> 04:37.983
+00:04:36.240 --> 00:04:40.799
 coding side of things on Emacs, I felt that, okay, that was
 
-04:39.355 --> 04:41.697
+00:04:40.800 --> 00:04:45.159
 something I needed to solve. So Elisp was always kind of
 
-04:41.877 --> 04:48.022
+00:04:45.160 --> 00:04:48.439
 just a toolkit that, you know, I knew that it was available. I
 
-04:48.322 --> 04:52.105
+00:04:48.440 --> 00:04:52.199
 knew that it would be something that I want to be able to use.
 
-04:52.646 --> 04:58.090
+00:04:52.200 --> 00:04:57.159
 So I think in a way color was a good segue to understand how I
 
-04:52.646 --> 04:58.090
+00:04:57.160 --> 00:05:03.359
 can kind of work out more of a complex logic with the editor
 
-04:59.136 --> 05:07.220
+00:05:03.360 --> 00:05:06.359
 without having to write JavaScript or things that I don't
 
-04:59.136 --> 05:07.220
+00:05:06.360 --> 00:05:09.399
 particularly like. So yeah, I think the journey around the
 
-05:07.440 --> 05:13.583
+00:05:09.400 --> 00:05:11.879
 functional languages, functional kind of programming was
 
-05:07.440 --> 05:13.583
+00:05:11.880 --> 00:05:15.439
 always something that I was keen about. And yeah, the whole
 
-05:13.943 --> 05:16.644
+00:05:15.440 --> 00:05:18.479
 journey kind of made sense for me. And then moving on to the
 
-05:16.984 --> 05:21.246
+00:05:18.480 --> 00:05:21.999
 color was just one way to get more involved in. So I can
 
-05:21.406 --> 05:27.069
+00:05:22.000 --> 00:05:26.279
 totally see that this journey kind of making to a little bit
 
-05:21.406 --> 05:27.069
+00:05:26.280 --> 00:05:30.759
 different angle But yeah, we shall see how that really turns
 
-05:27.669 --> 05:30.972
+00:05:30.760 --> 00:05:33.799
 out. But for now, I think I'm happy with the color setup. Now I
 
-05:33.514 --> 05:35.095
+00:05:33.800 --> 00:05:37.599
 can really focus on the coding. Well, that's all good. And
 
-05:37.156 --> 05:44.162
+00:05:37.600 --> 00:05:40.839
 I'm sure plenty of people listening to you now, you know,
 
-05:37.156 --> 05:44.162
+00:05:40.840 --> 00:05:43.639
 find this relatable, how they eventually got into
 
-05:37.156 --> 05:44.162
+00:05:43.640 --> 00:05:46.879
 programming. Like for you, you did say that you were a
 
-05:44.222 --> 05:47.745
+00:05:46.880 --> 00:05:50.519
 software engineer now. But I found plenty of people,
 
-05:48.705 --> 05:53.469
+00:05:50.520 --> 00:05:54.679
 especially doing workshops, that just started you know,
 
-05:54.339 --> 06:01.267
+00:05:54.680 --> 00:05:57.639
 their software engineering journey just with Emacs and
 
-05:54.339 --> 06:01.267
+00:05:57.640 --> 00:05:59.239
 they just realized they were doing something completely
 
-05:54.339 --> 06:01.267
+00:05:59.240 --> 00:06:01.999
 different, like I was studying humanities. But then you
 
-06:01.787 --> 00:06:02.687
+00:06:02.000 --> 00:06:05.079
 touch Emacs and you realize, yeah, this whole programming
 
-06:01.787 --> 06:06.693
+00:06:05.080 --> 00:06:06.679
 shtick is actually pretty damn cool.
 
-00:06:07.280 --> 00:06:09.399
+00:06:06.680 --> 00:06:09.079
 And then you find yourself again,
 
-00:06:09.400 --> 00:06:11.039
+00:06:09.080 --> 00:06:10.999
 five to 10 years later, becoming a software
 
-00:06:11.040 --> 00:06:12.919
+00:06:11.000 --> 00:06:12.999
 engineer. So yeah, that's all good.
 
-00:06:12.920 --> 00:06:14.519
+00:06:13.000 --> 00:06:13.919
 So we do have a couple of
 
-00:06:14.520 --> 00:06:18.439
+00:06:13.920 --> 00:06:18.439
 questions and I'd like to move into them so that I, I mean,
 
-00:06:18.440 --> 00:06:22.439
+00:06:18.440 --> 00:06:22.399
 people have questions and for me it's okay for me to chat with
 
-00:06:22.440 --> 00:06:25.119
+00:06:22.400 --> 00:06:25.119
 you but obviously it's better if people ask you the question
 
-00:06:25.120 --> 00:06:27.679
+00:06:25.120 --> 00:06:27.639
 themselves. And again, if you want to ask questions to Ryota
 
-00:06:27.680 --> 00:06:31.079
+00:06:27.640 --> 00:06:31.039
 directly, feel free to join us on BBB and whenever we're done
 
-00:06:31.080 --> 00:06:33.519
+00:06:31.040 --> 00:06:33.519
 with the questions on the pad, I'm more than happy
 
-00:06:33.520 --> 00:06:34.444
+00:06:33.520 --> 00:06:35.319
 to let you ask your questions live.
 
 NOTE Q: Is there any intention to create a library for working with more experimental color spaces? Pulling code out of Hasliberg for this purpose, perhaps?
 
-06:35.982 --> 00:06:37.902
+00:06:35.320 --> 00:06:37.799
 All right, so starting with the first question,
 
-00:06:37.903 --> 00:06:45.108
+00:06:37.800 --> 00:06:39.999
 is there any intention to create a library
 
-00:06:37.903 --> 06:45.108
+00:06:40.000 --> 00:06:42.559
 for working with more experimental color spaces, pulling
 
-06:35.982 --> 06:45.108
+00:06:42.560 --> 00:06:45.679
 code out of Hasliberg for this purpose, perhaps? Although I
 
-06:45.329 --> 06:46.049
+00:06:45.680 --> 00:06:50.479
 do not know. Hasliberg, you might? Yeah, Hasliberg. And to
 
-06:49.692 --> 06:50.892
+00:06:50.480 --> 00:06:55.119
 answer the question, started the journey just for myself
 
-06:52.859 --> 07:04.331
+00:06:55.120 --> 00:06:58.479
 and I didn't think that it would be actually useful for other
 
-06:52.859 --> 07:04.331
+00:06:58.480 --> 00:07:03.319
 use cases and this conference talk just came about kind of
 
-06:52.859 --> 07:04.331
+00:07:03.320 --> 00:07:08.079
 out of sheer luck really. So the idea I think I can definitely
 
-07:04.771 --> 07:14.501
+00:07:08.080 --> 00:07:12.199
 work it out and I don't think there will be too, the original
 
-07:04.771 --> 07:14.501
+00:07:12.200 --> 00:07:17.639
 code that I started with was I had to use some color space and I
 
-07:15.931 --> 07:21.595
+00:07:17.640 --> 00:07:22.479
 started with sRGB and then went to HSL and then went to LCH. So
 
-07:21.996 --> 07:24.678
+00:07:22.480 --> 00:07:25.479
 I think there has been quite a bit that I learned from it. At
 
-07:25.458 --> 07:33.885
+00:07:25.480 --> 00:07:29.999
 the same time, I may be tempted to actually maybe perhaps
 
-07:25.458 --> 07:33.885
+00:07:30.000 --> 00:07:34.159
 contribute back to ct.el rather than creating my own. I
 
-07:34.105 --> 07:36.227
+00:07:34.160 --> 00:07:36.279
 think that would make more sense perhaps.
 
-07:36.607 --> 00:07:39.548
+00:07:36.280 --> 00:07:39.479
 But for my own kind of taste that I thought
 
-00:07:39.549 --> 00:07:42.891
+00:07:39.480 --> 00:07:42.839
 that it would be something I can work out in my theme,
 
-00:07:42.892 --> 00:07:44.273
+00:07:42.840 --> 00:07:46.879
 but I don't have any I think, you know, making a
 
-07:45.813 --> 07:53.975
+00:07:46.880 --> 00:07:49.999
 library is definitely something that I can think about, but
 
-07:45.813 --> 07:53.975
+00:07:50.000 --> 00:07:53.679
 perhaps maybe making it too many packages isn't exactly
 
-07:45.813 --> 07:53.975
+00:07:53.680 --> 00:07:57.319
 what I want. But for my own use case, I think I just wanted to
 
-07:55.175 --> 08:06.317
+00:07:57.320 --> 00:07:59.919
 have something that just didn't have any external
 
-07:55.175 --> 08:06.317
+00:07:59.920 --> 00:08:04.119
 dependency so that I can use the vanilla Emacs with my
 
-07:55.175 --> 08:06.317
+00:08:04.120 --> 00:08:09.639
 colors. I think that's how it started, but I'm definitely up
 
-08:06.757 --> 08:11.558
+00:08:09.640 --> 00:08:13.719
 for it if there is interest about it. Yeah, well, thank you
 
-08:12.622 --> 00:08:13.615
+00:08:13.720 --> 00:08:15.279
 for this. It's always good to contribute.
 
-00:08:16.040 --> 00:08:16.399
+00:08:15.280 --> 00:08:16.399
 I'm tempted to say
 
-00:08:16.400 --> 00:08:18.679
+00:08:16.400 --> 00:08:18.279
 that's how they get you. You know, you do something really
 
-00:08:18.680 --> 00:08:24.799
+00:08:18.280 --> 00:08:23.639
 cool and you share it with people and they have the, you know,
 
-00:08:24.800 --> 00:08:27.080
+00:08:23.640 --> 00:08:27.239
 they just ask you, oh, do you have your code online? And you
 
-08:27.166 --> 08:28.667
+00:08:27.240 --> 00:08:29.399
 realize, no, I haven't pushed it. And then they start
 
-08:28.707 --> 08:30.107
+00:08:29.400 --> 00:08:32.359
 pressing you on. well, you need to do this, this is amazing
 
-08:30.287 --> 08:33.349
+00:08:32.360 --> 00:08:35.879
 and you need to share it. You know, I had plenty of people ask
 
-08:33.849 --> 08:41.735
+00:08:35.880 --> 00:08:40.519
 me to share my dot files when I was tackling the org agenda
 
-08:33.849 --> 08:41.735
+00:08:40.520 --> 00:08:44.039
 issue that I mentioned earlier. And yeah, eventually when
 
-08:42.575 --> 08:54.243
+00:08:44.040 --> 00:08:47.479
 you get to publishing your stuff, you also feel great
 
-08:42.575 --> 08:54.243
+00:08:47.480 --> 00:08:50.279
 because you're putting a little bit of your intelligence
 
-08:42.575 --> 08:54.243
+00:08:50.280 --> 00:08:53.679
 into the world and it can be the start of the journey for
 
-08:42.575 --> 08:54.243
+00:08:53.680 --> 00:08:56.239
 someone else. You know, maybe someone will find your
 
-08:54.283 --> 08:59.867
+00:08:56.240 --> 00:08:58.679
 library at some point and realize, yeah, I wanted to do
 
-08:54.283 --> 08:59.867
+00:08:58.680 --> 00:09:01.239
 something slightly differently. and then they either
 
-09:00.387 --> 09:10.793
+00:09:01.240 --> 00:09:04.439
 contribute to a library or they make their own but it's a
 
-09:00.387 --> 09:10.793
+00:09:04.440 --> 00:09:07.359
 complete journey that starts with just people taking the
 
-09:00.387 --> 09:10.793
+00:09:07.360 --> 00:09:12.039
 time to publish the content of the brain basically. Yeah,
 
-09:11.894 --> 09:13.354
+00:09:12.040 --> 00:09:15.519
 that's the power of open source now. It's just how we really
 
-09:13.654 --> 09:21.276
+00:09:15.520 --> 00:09:19.119
 appreciate the open source culture being cultivated
 
-09:13.654 --> 09:21.276
+00:09:19.120 --> 00:09:23.159
 throughout so many years. And yeah, this is something that
 
-09:21.736 --> 09:24.337
+00:09:23.160 --> 00:09:26.999
 I'm definitely keen about. So yeah, open for suggestions.
 
-09:26.618 --> 09:29.298
+00:09:27.000 --> 00:09:30.079
 And exactly, that's how I started with the journey. And
 
-00:09:29.760 --> 00:09:33.559
+00:09:30.080 --> 00:09:33.519
 yeah, while this is very experimental and very personal,
 
-00:09:33.560 --> 00:09:38.239
+00:09:33.520 --> 00:09:38.199
 yeah, I'm not, you know, tied down to one particular way
 
-00:09:38.240 --> 00:09:41.679
+00:09:38.200 --> 00:09:41.399
 only. So yeah we'll be open to suggestions like this one
 
-00:09:41.680 --> 00:09:44.839
+00:09:41.400 --> 00:09:44.719
 which I would definitely think about. Yeah that's amazing
 
-00:09:44.840 --> 00:09:46.879
+00:09:44.720 --> 00:09:46.999
 and just to be clear you know this is not a there's no
 
-00:09:46.880 --> 00:09:47.840
+00:09:47.000 --> 00:09:50.639
 incentive one. I'm not pushing you to publish your library.
 
-09:51.070 --> 09:57.595
+00:09:50.640 --> 00:09:53.799
 You know it was very personal for you and at the end if you
 
-09:51.070 --> 09:57.595
+00:09:53.800 --> 00:09:56.199
 believe it might be useful for others it's a nice thing to
 
-09:51.070 --> 09:57.595
+00:09:56.200 --> 00:09:58.799
 eventually think about publishing it. But just the fact
 
-09:58.056 --> 10:00.117
+00:09:58.800 --> 00:10:01.439
 that you showed up at EmacsConf... Sorry, I'm
 
-10:01.278 --> 00:10:02.698
+00:10:01.440 --> 00:10:02.639
 starting to lose my voice on the morning
 
-00:10:02.699 --> 00:10:03.280
+00:10:02.640 --> 00:10:03.839
 of the first day. That's
 
-10:03.520 --> 00:10:08.559
+00:10:03.840 --> 00:10:07.639
 not boding well for the two next days. I mean, just one day.
 
-00:10:08.560 --> 00:10:10.079
+00:10:07.640 --> 00:10:09.159
 But just the
 
-00:10:10.080 --> 00:10:13.279
+00:10:09.160 --> 00:10:13.199
 fact that you're showing up at EmacsConf and sharing about
 
-00:10:13.280 --> 00:10:17.119
+00:10:13.200 --> 00:10:17.039
 all of this, the process, how you got to it eventually, it's
 
-00:10:17.120 --> 00:10:19.439
+00:10:17.040 --> 00:10:19.639
 also a part of sharing. And I think it's also amazing in its
 
-00:10:19.440 --> 00:10:26.039
+00:10:19.640 --> 00:10:26.039
 own way. Absolutely. Okay, I'm going to try to read the next
 
-00:10:26.040 --> 00:10:31.719
+00:10:26.040 --> 00:10:31.639
 question and then try to cough a little bit. So can we have...
 
-00:10:31.720 --> 00:10:36.919
+00:10:31.640 --> 00:10:36.759
 Oh, sorry, Bala. Sorry. I was the one who asked the question.
 
-00:10:36.920 --> 00:10:40.120
+00:10:36.760 --> 00:10:40.279
 I thought I could ask it live here rather than... Thank you.
 
-10:40.188 --> 10:41.368
+00:10:40.280 --> 00:10:46.039
 I'll go cough a little bit. So here I am. Thanks, Ryota, for
 
-10:45.050 --> 10:47.190
+00:10:46.040 --> 00:10:50.519
 the nice talk. This is great. I loved it. Your attention to
 
-10:49.531 --> 00:10:50.140
+00:10:50.520 --> 00:10:51.519
 detail was awesome.
 
 NOTE Q: Can we have a dark as well as light theme variations made from your theme?
 
-00:10:51.880 --> 00:10:55.079
+00:10:51.520 --> 00:10:54.959
 So I was just looking at the code and I was
 
-00:10:55.080 --> 00:10:58.839
+00:10:54.960 --> 00:10:58.759
 wondering, do you have a dark and a light theme variation
 
-00:10:58.840 --> 00:11:02.479
+00:10:58.760 --> 00:11:02.599
 which can be made from your theme? Or do you have to customize
 
-00:11:02.480 --> 00:11:05.519
+00:11:02.600 --> 00:11:06.199
 it every time? That was my question. And thanks for that.
 
-00:11:05.520 --> 00:11:07.640
+00:11:06.200 --> 00:11:09.679
 Thank you very much. I appreciate your feedback and
 
-00:11:10.240 --> 00:11:15.079
+00:11:09.680 --> 00:11:15.039
 questions. So to answer the question, the short answer is
 
-00:11:15.080 --> 00:11:18.639
+00:11:15.040 --> 00:11:18.439
 that I do have both dark and light themes with some sorts of
 
-00:11:18.640 --> 00:11:22.199
+00:11:18.440 --> 00:11:22.199
 standard colors that I personally liked. And there were a
 
-00:11:22.200 --> 00:11:26.719
+00:11:22.200 --> 00:11:26.679
 few things that I showed in the demo. where I showed, I think,
 
-00:11:26.720 --> 00:11:30.039
+00:11:26.680 --> 00:11:29.999
 three different dark theme colors. So light theme is
 
-00:11:30.040 --> 00:11:31.440
+00:11:30.000 --> 00:11:31.559
 definitely something that I can do.
 
-00:11:31.800 --> 00:11:33.879
+00:11:31.560 --> 00:11:33.759
 And the idea around Hasliberg theme
 
-00:11:33.880 --> 00:11:36.359
+00:11:33.760 --> 00:11:36.279
 and just my theming in general was that
 
-00:11:36.360 --> 00:11:39.679
+00:11:36.280 --> 00:11:39.599
 when I feel like I want to work in dark theme and when I want to
 
-00:11:39.680 --> 00:11:42.440
+00:11:39.600 --> 00:11:42.159
 work in the standard way, I would just use the standard color.
 
-00:11:42.480 --> 00:11:44.959
+00:11:42.160 --> 00:11:44.919
 But when I feel like maybe it's just so cold that I want
 
-00:11:44.960 --> 00:11:49.399
+00:11:44.920 --> 00:11:48.519
 to have a bit of a warm colors near me, I would use the orange
 
-00:11:49.400 --> 00:11:52.359
+00:11:48.520 --> 00:11:52.279
 theme, without changing too much of the kind of general
 
-00:11:52.360 --> 00:11:55.679
+00:11:52.280 --> 00:11:55.639
 feeling and experience. So that can be said for the light
 
-00:11:55.680 --> 00:11:58.959
+00:11:55.640 --> 00:11:58.959
 theme as well. So there is something and the kind of
 
-00:11:58.960 --> 00:12:04.919
+00:11:58.960 --> 00:12:04.839
 customization isn't that difficult to extend. So I do have
 
-00:12:04.920 --> 00:12:09.079
+00:12:04.840 --> 00:12:09.359
 both dark and light, but primarily I'm just looking at the
 
-00:12:09.080 --> 00:12:10.239
+00:12:09.360 --> 00:12:12.839
 dark theme as my main driver. But yeah, they are both
 
-00:12:10.240 --> 00:12:13.240
+00:12:12.840 --> 00:12:18.239
 available. Great. Thank you so much. I will definitely try
 
-00:12:18.208 --> 12:18.865
+00:12:18.240 --> 00:12:21.719
 your theme out. I'm definitely on the lookout for a nice,
 
-12:19.205 --> 12:22.426
+00:12:21.720 --> 00:12:26.119
 friendly theme. Thank you very much. As I said, this is a
 
-12:25.388 --> 12:27.429
+00:12:26.120 --> 00:12:31.279
 personal theme. I'm not sure if it really fits everyone's
 
-12:29.089 --> 12:42.816
+00:12:31.280 --> 00:12:37.159
 need, but it is one inspiration that I hope that can lead to
 
-12:29.089 --> 12:42.816
+00:12:37.160 --> 00:12:40.639
 another nice theming that could work for someone
 
-12:29.089 --> 12:42.816
+00:12:40.640 --> 00:12:44.199
 specifically for some use cases. I don't have to solve
 
-12:42.996 --> 12:44.977
+00:12:44.200 --> 00:12:48.719
 everyone's problem. Yeah, and I mean, it was sufficient to
 
-12:46.553 --> 12:49.715
+00:12:48.720 --> 00:12:50.719
 be inspirational to people. I mean, just Bala just
 
-12:49.755 --> 12:58.619
+00:12:50.720 --> 00:12:53.759
 mentioned it right now, but I'm sure plenty of people who
 
-12:49.755 --> 12:58.619
+00:12:53.760 --> 00:12:55.999
 watched live, but also people will be watching in the
 
-12:49.755 --> 12:58.619
+00:12:56.000 --> 00:12:58.599
 future, will have the interest to speak by what you've done.
 
-12:58.699 --> 13:00.040
+00:12:58.600 --> 00:13:05.079
 So thank you again so much for this. Yep. All right, well, I
 
-13:04.102 --> 13:06.603
+00:13:05.080 --> 00:13:09.719
 don't see any further questions. So I suggest we move
 
-13:07.083 --> 13:10.525
+00:13:09.720 --> 00:13:14.279
 towards closure. Ryota, do you have any last words? No, I
 
-13:13.775 --> 13:14.175
+00:13:14.280 --> 00:13:17.079
 don't. So yeah, thank you very much for attending. And it was
 
-13:16.577 --> 13:18.979
+00:13:17.080 --> 00:13:20.519
 great fun putting this together. And I really didn't think
 
-13:19.299 --> 13:27.545
+00:13:20.520 --> 00:13:24.759
 that I would be talking about my personal colors and
 
-13:19.299 --> 13:27.545
+00:13:24.760 --> 00:13:27.759
 personal favorites, like orange being my favorite color.
 
-13:27.845 --> 13:31.228
+00:13:27.760 --> 00:13:30.119
 This wouldn't be something that I would say out in any
 
-13:27.845 --> 13:31.228
+00:13:30.120 --> 00:13:34.159
 conference, to be honest. But it just came out to be. And
 
-13:33.890 --> 13:35.491
+00:13:34.160 --> 00:13:37.479
 happy that I had a chance. So thank you very much for giving me
 
-13:35.651 --> 13:39.154
+00:13:37.480 --> 00:13:41.439
 the opportunity to talk. in this amazing conference and
 
-13:39.574 --> 13:52.473
+00:13:41.440 --> 00:13:44.319
 yeah I can't just wait to check out other talks which you know
 
-13:39.574 --> 13:52.473
+00:13:44.320 --> 00:13:46.919
 I know that there isn't you know other talks that are
 
-13:39.574 --> 13:52.473
+00:13:46.920 --> 00:13:50.199
 happening right now I was actually wanted to to join them and
 
-13:39.574 --> 13:52.473
+00:13:50.200 --> 00:13:52.759
 check check that out so I will probably do that right now.
 
-13:53.419 --> 13:53.899
+00:13:52.760 --> 00:13:56.839
 Well, sure. Well, I won't hold you any longer then. Thank
 
-13:56.401 --> 13:56.741
+00:13:56.840 --> 00:13:59.759
 you. For me, it was just amazing to, you know, generally when
 
-13:57.682 --> 14:03.285
+00:13:59.760 --> 00:14:01.639
 you ask someone what their favorite color, you know, they
 
-13:57.682 --> 14:03.285
+00:14:01.640 --> 00:14:04.399
 just tell you orange or blue or whatever. They don't go then
 
-14:03.586 --> 14:10.690
+00:14:04.400 --> 00:14:07.039
 to chat about 20 minutes about their favorite color and how
 
-14:03.586 --> 14:10.690
+00:14:07.040 --> 00:14:10.079
 they tuned their entire editor to work exactly around their
 
-14:03.586 --> 14:10.690
+00:14:10.080 --> 00:14:14.759
 favorite colors. So it was inspiring. And I also want to try
 
-14:12.912 --> 14:21.057
+00:14:14.760 --> 00:14:17.999
 it out, frankly, because my theme has been utterly bad for
 
-14:12.912 --> 14:21.057
+00:14:18.000 --> 00:14:20.639
 the last five years and I need some change into my life. All
 
-14:21.497 --> 14:21.677
+00:14:20.640 --> 00:14:24.319
 right. Thank you so much for your time. Thank you very much,
 
-14:23.629 --> 14:24.654
+00:14:24.320 --> 00:14:30.640
 everyone. Cheers. Bye-bye.
+
diff --git a/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt b/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
index 0142a879..7c2708d9 100644
--- a/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
+++ b/2024/captions/emacsconf-2024-gypsum--gypsum-my-clone-of-emacs-and-elisp-written-in-scheme--ramin-honary--answers.vtt
@@ -1,725 +1,725 @@
 WEBVTT
 
-00:00.069 --> 00:01.850
-Troy Hinckley's project that I'm talking about. I was going
+00:00:00.000 --> 00:00:02.999
+...Troy Hinckley's project that I'm talking about. I was going
 
-00:02.350 --> 00:22.139
+00:00:03.000 --> 00:00:08.799
 to mention this in my presentation, but it's possible,
 
-00:02.350 --> 00:22.139
+00:00:08.800 --> 00:00:16.359
 theoretically, that Troy Hinckley, his project could be
 
-00:02.350 --> 00:22.139
+00:00:16.360 --> 00:00:18.559
 used as a scheme of limitation that actually runs my own
 
-00:02.350 --> 00:22.139
+00:00:18.560 --> 00:00:23.759
 version of Emacs. And although, you know, This is
 
-00:25.478 --> 00:29.380
+00:00:23.760 --> 00:00:30.719
 completely theoretical, and I don't know how difficult
 
-00:25.478 --> 00:29.380
+00:00:30.720 --> 00:00:34.079
 that would be. But if Troy Hinckley implemented enough of
 
-00:30.781 --> 00:47.029
+00:00:34.080 --> 00:00:39.879
 the R7-RS standard in Rust, it would theoretically be
 
-00:30.781 --> 00:47.029
+00:00:39.880 --> 00:00:46.719
 possible to run the Gypsum editor in Troy Hinckley's own
 
-00:30.781 --> 00:47.029
+00:00:46.720 --> 00:00:50.239
 editor. I thought that was kind of interesting, and I
 
-00:48.270 --> 00:53.833
+00:00:50.240 --> 00:00:59.119
 thought it was worth mentioning, at least in the questions
 
-00:48.270 --> 00:53.833
+00:00:59.120 --> 00:01:12.159
 and answers.
 
-01:12.179 --> 01:14.080
+00:01:12.160 --> 00:01:16.199
 I also mentioned this in the presentation. I wanted to see
 
-01:14.940 --> 01:22.364
+00:01:16.200 --> 00:01:20.119
 Robin Templeton's project presentation, but
 
-01:14.940 --> 01:22.364
+00:01:20.120 --> 00:01:22.399
 unfortunately it's going to be at like four in the morning
 
-01:14.940 --> 01:22.364
+00:01:22.400 --> 00:01:26.239
 for me. So I'm going to try and watch that tomorrow, but
 
-01:22.984 --> 01:31.428
+00:01:26.240 --> 00:01:29.559
 that's also going to be a very interesting project to keep an
 
-01:22.984 --> 01:31.428
+00:01:29.560 --> 00:01:34.039
 eye on if you're interested in Scheme. That's the project
 
-01:33.149 --> 01:38.051
+00:01:34.040 --> 00:01:37.519
 where you've got the Guylain interpreter running inside of
 
-01:33.149 --> 01:38.051
+00:01:37.520 --> 00:02:04.679
 the Emacs process. It's dynamically linked as a library.
 
-02:04.699 --> 02:06.748
+00:02:04.680 --> 00:02:08.759
 I'm ready for questions from anybody. You can ask or you can
 
-02:07.431 --> 02:09.079
+00:02:08.760 --> 00:02:32.079
 type. It's up to you.
 
-02:32.319 --> 02:34.521
+00:02:32.080 --> 00:02:37.319
 Okay, let me check the etherpad.
 
-02:37.304 --> 02:38.245
+00:02:37.320 --> 00:02:41.159
 Let's see here.
 
-02:41.208 --> 02:42.830
+00:02:41.160 --> 00:02:42.719
 I'm not sure if I'm doing that right.
 
-02:46.373 --> 02:47.554
+00:02:42.720 --> 00:02:54.199
 Let me check one more time. Oh, there it goes.
 
-02:54.221 --> 02:55.702
+00:02:54.200 --> 00:03:00.079
 Let's see, so this is...
 
-03:00.151 --> 03:02.072
+00:03:00.080 --> 00:03:02.239
 I didn't know about that first bit of history. Oh, I've heard
 
-03:02.332 --> 00:03:09.369
+00:03:02.240 --> 00:03:06.119
 RMS say that Scheme Guile is just a nicer Lisp, but I didn't
 
-03:02.332 --> 03:09.776
+00:03:06.120 --> 00:03:09.079
 know there were concrete talks attempts to use Guile for
 
-03:02.332 --> 03:09.776
+00:03:09.080 --> 00:03:14.319
 Emacs that early. Let's see, that was from janneke.
 
 NOTE Q: I'm curious to know how the hell guile-emacs deals with all of the dynamically scoped modules out there. Is there any effort to automatically modularize and namespace stuff?
 
-00:03:09.370 --> 00:03:19.241
+00:03:14.320 --> 00:03:17.439
 I'm curious to know how the hell Guile Emacs deals with all the
 
-03:14.318 --> 03:19.241
+00:03:17.440 --> 00:03:21.359
 dynamically scoped modules out there. Is there any effort
 
-03:20.181 --> 03:24.943
+00:03:21.360 --> 00:03:29.759
 to automatically modularize and name? Let's see.
 
-03:30.523 --> 03:35.806
+00:03:29.760 --> 00:03:40.919
 That might be a better question for Robin Templeton. In my
 
-03:36.727 --> 03:46.573
+00:03:40.920 --> 00:03:44.639
 own project,
 
-03:36.727 --> 03:46.573
+00:03:44.640 --> 00:03:49.399
 there's no module system for Emacs Lisp. There is a module
 
-03:46.693 --> 03:48.234
+00:03:49.400 --> 00:03:55.559
 system for Scheme. And the Emacs Lisp interpreter runs in
 
-03:49.695 --> 03:55.158
+00:03:55.560 --> 00:04:01.599
 its own environment. the require system or whatever module
 
-03:57.068 --> 04:11.736
+00:04:01.600 --> 00:04:06.359
 system that Emacs has, once it's implemented, all of that
 
-03:57.068 --> 04:11.736
+00:04:06.360 --> 00:04:09.759
 would just happen inside of the Emacs Lisp environment,
 
-03:57.068 --> 04:11.736
+00:04:09.760 --> 00:04:12.399
 which is inside of the Scheme environment. And
 
-04:12.437 --> 04:15.898
+00:04:12.400 --> 00:04:21.479
 environments are objects in Scheme.
 
-04:21.522 --> 04:24.103
+00:04:21.480 --> 00:04:26.399
 I think a more difficult question is how to handle
 
-04:26.420 --> 04:31.942
+00:04:26.400 --> 00:04:33.279
 threading, and Scheme has very good threading built in, in
 
-04:26.420 --> 04:31.942
+00:04:33.280 --> 00:04:34.839
 Serphe-18[??].
 
-04:34.283 --> 04:48.028
+00:04:34.840 --> 00:04:43.399
 But I don't think it will be easy to write Emacs Lisp form
 
-04:34.283 --> 04:48.028
+00:04:43.400 --> 00:04:48.479
 bindings to the Scheme multi-threading implementation.
 
-04:48.548 --> 04:50.749
+00:04:48.480 --> 00:04:52.279
 Emacs Lisp was just not cut out for that kind of thing. So I
 
-04:51.710 --> 04:59.894
+00:04:52.280 --> 00:04:56.559
 think each Emacs Lisp, you could, I suppose, have multiple
 
-04:51.710 --> 04:59.894
+00:04:56.560 --> 00:05:00.039
 threads each running their own Emacs Lisp environment.
 
-05:01.375 --> 05:02.956
+00:05:00.040 --> 00:05:04.999
 Scheme would make that very simple to do.
 
-05:06.018 --> 05:16.744
+00:05:05.000 --> 00:05:08.759
 And then there'd just be a question of how you would get those
 
-05:06.018 --> 05:16.744
+00:05:08.760 --> 00:05:11.679
 different interpreters to communicate with each other,
 
-05:06.018 --> 05:16.744
+00:05:11.680 --> 00:05:16.279
 perhaps using the same protocol that's used by the Emacs
 
-05:06.018 --> 05:16.744
+00:05:16.280 --> 00:05:23.639
 server. But I haven't thought that far ahead yet.
 
 NOTE Q: Would it be possible to support a GUI toolkit other than GTK?
 
-05:23.646 --> 05:28.709
+00:05:23.640 --> 00:05:26.839
 Would it be possible to support a GUI toolkit other than the
 
-05:23.646 --> 05:28.709
+00:05:26.840 --> 00:05:31.319
 GTK? Like, how is it still supports Lucid? Yes, this is
 
-05:31.291 --> 05:33.232
+00:05:31.320 --> 00:05:36.999
 absolutely a goal of the project. I'm trying to keep the back
 
-05:33.873 --> 05:38.416
+00:05:37.000 --> 00:05:41.599
 end separate as possible. The scheme has what you call
 
-05:39.817 --> 05:42.478
+00:05:41.600 --> 00:05:45.239
 parameters. And these are like global variables that are
 
-05:43.199 --> 05:46.221
+00:05:45.240 --> 00:05:50.519
 still somewhat thread safe. And every call to the GUI goes
 
-05:47.484 --> 05:51.225
+00:05:50.520 --> 00:05:58.199
 through a parameter. So the Emacs, the interpreter and the
 
-05:52.125 --> 05:59.367
+00:05:58.200 --> 00:06:01.679
 editor logic is all in one module. And then that module calls
 
-05:59.987 --> 06:04.309
+00:06:01.680 --> 00:06:06.319
 out into a separate GUI module. And then you can implement
 
-06:04.989 --> 06:07.690
+00:06:06.320 --> 00:06:11.599
 different GUI modules. So you could have one for GTK3, one
 
-06:08.430 --> 06:13.171
+00:06:11.600 --> 00:06:16.879
 for GTK4, if you want to write the extern C bindings around Qt
 
-06:13.843 --> 06:20.725
+00:06:16.880 --> 00:06:21.199
 or full tick, that would certainly be possible as well. It
 
-06:21.185 --> 06:32.168
+00:06:21.200 --> 00:06:25.919
 would be nice maybe to have an SDL implementation based
 
-06:21.185 --> 06:32.168
+00:06:25.920 --> 00:06:30.999
 maybe on Chikiti or some kind of immediate mode GUI,
 
-06:21.185 --> 06:32.168
+00:06:31.000 --> 00:06:37.399
 something like that. But definitely GTK3 through Guile GI
 
-06:33.808 --> 06:38.750
+00:06:37.400 --> 00:06:41.319
 is the reference implementation. Things start there. But
 
-06:41.298 --> 06:43.959
+00:06:41.320 --> 00:06:43.999
 I'm very interested in supporting other GUIs, yes. Let's
 
-06:45.199 --> 00:06:45.256
+00:06:44.000 --> 00:06:46.039
 see.
 
 NOTE Q: Do you plan to provide improvements to Elisp as a language, or is the focus on a compatibility layer to facilitate doing all new extensions, etc. in Scheme?
 
-00:06:45.257 --> 00:06:45.879
+00:06:46.040 --> 00:06:50.759
 Question, do you plan to provide improvements to ELisp
 
-06:47.540 --> 06:56.342
+00:06:50.760 --> 00:06:54.519
 as a language or focus on a compatibility layer to
 
-06:47.540 --> 06:56.342
+00:06:54.520 --> 00:06:57.999
 facilitate all new extensions in Scheme? Yeah, the second
 
-06:57.142 --> 06:57.962
+00:06:58.000 --> 00:07:04.719
 one. I want to move off to Scheme. I would like for this
 
-07:03.384 --> 07:05.264
+00:07:04.720 --> 00:07:08.999
 project to try and keep up to date with each new release of
 
-07:05.666 --> 07:10.789
+00:07:09.000 --> 00:07:13.799
 Emacs and Emacs Lisp. That's a difficult moving target to
 
-07:11.850 --> 07:14.552
+00:07:13.800 --> 00:07:18.639
 follow, I realize. But to the greatest extent possible, any
 
-07:15.152 --> 07:23.397
+00:07:18.640 --> 00:07:25.239
 new features to Emacs Lisp will be pulled in from GNU Emacs.
 
-07:25.419 --> 07:29.041
+00:07:25.240 --> 00:07:28.599
 If we happen to be able to implement something cool in
 
-07:25.419 --> 07:29.041
+00:07:28.600 --> 00:07:31.639
 Scheme, and be able to port it over to Emacs Lisp, then sure,
 
-07:29.437 --> 07:36.543
+00:07:31.640 --> 00:07:35.799
 it'd be nice to be able to upload or to submit that upstream to
 
-07:29.437 --> 07:36.543
+00:07:35.800 --> 00:07:43.079
 the GNU Emacs. But I think I would prefer to have new features
 
-07:38.584 --> 07:43.708
+00:07:43.080 --> 00:07:47.799
 written in Scheme. I would like this gypsum to be more of a
 
-07:43.989 --> 07:52.075
+00:07:47.800 --> 00:07:51.479
 Scheme app platform that just happens to be able to also run
 
-07:43.989 --> 07:52.075
+00:07:51.480 --> 00:07:56.199
 Emacs Lisp. That's how I see it. Of course, this will be a
 
-07:54.577 --> 07:56.699
+00:07:56.200 --> 00:08:00.799
 community project. I'm open to debate about that if anybody
 
-07:58.809 --> 08:02.012
+00:08:00.800 --> 00:08:02.079
 wants to convince me otherwise.
 
-08:08.439 --> 08:11.683
+00:08:02.080 --> 00:08:11.759
 Why is being able to interpret all of that EL a useful goal?
 
-08:12.464 --> 08:14.626
+00:08:11.760 --> 00:08:15.519
 Sure, there is a lot of code written in Elisp. Can we
 
-08:15.206 --> 08:17.749
+00:08:15.520 --> 00:08:18.959
 consider... Oh, it's still being written. Please go ahead
 
-08:18.390 --> 08:19.491
+00:08:18.960 --> 00:08:19.439
 and finish writing.
 
 NOTE Q: Can we consider a translator like utility to convert elisp to scheme, once guile-emacs becomes a reality?
 
-08:29.673 --> 08:35.576
+00:08:19.440 --> 00:08:32.519
 Can we consider a translator like utility to convert eLisp
 
-08:29.673 --> 08:35.576
+00:08:32.520 --> 00:08:37.519
 to Scheme once Guile-Emacs has become a reality?
 
-08:36.716 --> 08:37.076
+00:08:37.520 --> 00:08:42.119
 Certainly. For the time being, I just wanted to get the
 
-08:38.717 --> 08:42.639
+00:08:42.120 --> 00:08:47.559
 interpreter running. So the actual, the Guile-Emacs Lisp,
 
-08:44.520 --> 08:58.666
+00:08:47.560 --> 00:08:51.919
 the one that was written in 2011 that I didn't write, that
 
-08:44.520 --> 08:58.666
+00:08:51.920 --> 00:08:57.599
 actually does compile to, I think it's the tree
 
-08:44.520 --> 08:58.666
+00:08:57.600 --> 00:08:59.239
 intermediate representation It's one of the intermediate
 
-08:59.076 --> 09:03.697
+00:08:59.240 --> 00:09:03.759
 languages that Guile uses to compile Guile scheme itself.
 
-09:04.817 --> 09:09.299
+00:09:03.760 --> 00:09:09.079
 So the Emacs lisp that was written before actually does
 
-09:04.817 --> 09:09.299
+00:09:09.080 --> 00:09:13.119
 that. It actually compiles and makes use of the entire Guile
 
-09:09.339 --> 09:20.761
+00:09:13.120 --> 00:09:17.479
 compiler tool chain and actually produces like JIT
 
-09:09.339 --> 09:20.761
+00:09:17.480 --> 00:09:21.719
 compilable binaries, which is really cool. Like I said,
 
-09:23.342 --> 09:25.943
+00:09:21.720 --> 00:09:27.519
 that's the one that I had trouble getting to work properly.
 
-09:29.209 --> 09:30.890
+00:09:27.520 --> 00:09:34.399
 Maybe we can follow that architecture. I'm not sure how to do
 
-09:33.052 --> 09:45.102
+00:09:34.400 --> 00:09:37.919
 that, but I would like to be able to do some kind of
 
-09:33.052 --> 09:45.102
+00:09:37.920 --> 00:09:41.999
 translating, keeping in mind that we want to have this be
 
-09:33.052 --> 09:45.102
+00:09:42.000 --> 00:09:48.919
 portable, do various schemes. And so Guile makes this very
 
-09:45.988 --> 09:50.289
+00:09:48.920 --> 00:09:52.719
 easy, but other schemes don't. Gambit might do this pretty
 
-09:51.549 --> 09:53.530
+00:09:52.720 --> 00:09:57.919
 well as well. It compiles to C and then compiles C down to a
 
-09:53.950 --> 10:01.471
+00:09:57.920 --> 00:10:06.159
 dynamically linkable library. So yeah, I think probably
 
-10:03.372 --> 10:09.373
+00:10:06.160 --> 00:10:09.559
 the most portable, I'm just thinking out loud right now,
 
-10:10.652 --> 10:21.715
+00:10:09.560 --> 00:10:13.239
 most portable implementation will just be able to
 
-10:10.652 --> 10:21.715
+00:10:13.240 --> 00:10:17.119
 translate Emacs Lisp directly to Scheme, which is not what
 
-10:10.652 --> 10:21.715
+00:10:17.120 --> 00:10:22.439
 the old Guile Emacs Lisp implementation does. That goes to
 
-10:21.755 --> 10:26.777
+00:10:22.440 --> 00:10:26.439
 TreeIL, so it's very, very Guile-specific, can't be
 
-10:21.755 --> 10:26.777
+00:10:26.440 --> 00:10:30.799
 ported. But yeah, if we could somehow get Emacs Lisp
 
-10:28.359 --> 10:42.045
+00:10:30.800 --> 00:10:36.999
 translated to Scheme and then compiled, say, in Shea Scheme
 
-10:28.359 --> 10:42.045
+00:10:37.000 --> 00:10:40.879
 or Gambit or MIT Scheme or one of those other compilers, that
 
-10:28.359 --> 10:42.045
+00:10:40.880 --> 00:10:44.919
 would be very cool. And I would absolutely love to do that.
 
-10:44.906 --> 10:49.948
+00:10:44.920 --> 00:10:49.279
 And I would very quickly accept any code into the code base
 
-10:44.906 --> 10:49.948
+00:10:49.280 --> 00:10:50.599
 that would do that.
 
 NOTE Q: Why is being able to interpret all of \`init.el\` an useful goal?
 
-10:54.390 --> 10:56.291
+00:10:50.600 --> 00:10:59.119
 Oh, and to answer the question about init.el,
 
-10:59.207 --> 11:17.215
+00:10:59.120 --> 00:11:02.839
 It's just because people spend a lot of time on their configs
 
-10:59.207 --> 11:17.215
+00:11:02.840 --> 00:11:06.959
 and it would be nice if, you know, you're starting to use this
 
-10:59.207 --> 11:17.215
+00:11:06.960 --> 00:11:14.079
 new editor and want it to be similar to Emacs users, just the
 
-10:59.207 --> 11:17.215
+00:11:14.080 --> 00:11:16.519
 Emacs community in general and people who are familiar with
 
-10:59.207 --> 11:17.215
+00:11:16.520 --> 00:11:20.879
 using Emacs. It would be more useful to everybody in the
 
-11:17.715 --> 11:25.379
+00:11:20.880 --> 00:11:25.119
 Emacs community if this were more compatible with GNU
 
-11:17.715 --> 11:25.379
+00:11:25.120 --> 00:11:35.999
 Emacs. And so that's why that's, I think that's an important
 
-11:25.679 --> 11:27.960
+00:11:36.000 --> 00:11:38.559
 goal.
 
-11:34.465 --> 11:35.467
+00:11:38.560 --> 00:12:01.839
 Question is not yet. Great. Oh, here comes another
 
-11:38.471 --> 11:39.613
+00:12:01.840 --> 00:12:02.279
 question.
 
 NOTE Q: What is the plan to handle elisp packages that depend on 3rd party/external libraries? (libgit/magit or rg/ripgrep)?
 
-12:08.539 --> 12:17.742
+00:12:02.280 --> 00:12:11.879
 Okay, what is the plan to handle elisp packages that depend
 
-12:08.539 --> 12:17.742
+00:12:11.880 --> 00:12:16.119
 on third-party or external libraries like git or magit
 
-12:08.539 --> 12:17.742
+00:12:16.120 --> 00:12:22.719
 or ripgrep? So that's going to be tricky. It depends on how
 
-12:21.523 --> 12:26.224
+00:12:22.720 --> 00:12:27.079
 these external packages are linked into emacs. If it's
 
-12:26.844 --> 12:33.646
+00:12:27.080 --> 00:12:32.879
 going to be a dynamic library like Robin Templeton's
 
-12:26.844 --> 12:33.646
+00:12:32.880 --> 00:12:38.039
 project which you load the libgit library into the Emacs
 
-12:35.289 --> 12:41.931
+00:12:38.040 --> 00:12:43.159
 process, that is going to be extremely difficult. So if you
 
-12:44.032 --> 12:52.975
+00:12:43.160 --> 00:12:49.359
 have an external library like, I don't know, libgit or
 
-12:44.032 --> 12:52.975
+00:12:49.360 --> 00:12:59.279
 what's the GUI thing? Cabal. No, not Cabal. Cairo, libcairo
 
-12:57.736 --> 13:01.398
+00:12:59.280 --> 00:13:01.439
 to do SVG graphics and so on.
 
-13:04.483 --> 13:17.480
+00:13:01.440 --> 00:13:09.719
 You can do that very easily with Guile, but then on top of
 
-13:04.483 --> 13:17.480
+00:13:09.720 --> 00:13:14.719
 that, implementing Emacs list bindings to it, I mean,
 
-13:04.483 --> 13:17.480
+00:13:14.720 --> 00:13:17.199
 you've got two layers there, and that makes things pretty
 
-13:04.483 --> 13:17.480
+00:13:17.200 --> 00:13:23.119
 difficult. So it's possible. And to some degree, maybe
 
-13:21.935 --> 13:30.842
+00:13:23.120 --> 00:13:27.799
 necessary for example, Cairo, if we want to do SVG graphics
 
-13:21.935 --> 13:30.842
+00:13:27.800 --> 00:13:30.599
 the way that Emacs Lisp does, we're going to have to have
 
-13:21.935 --> 13:30.842
+00:13:30.600 --> 00:13:33.959
 that. So that would be necessary. We would have to have those
 
-13:32.643 --> 13:33.944
+00:13:33.960 --> 00:13:39.199
 two layers. Yes, let's do that. But if it's like for Magit,
 
-13:38.047 --> 13:50.596
+00:13:39.200 --> 00:13:45.479
 you can just call out to your git process, and then you're
 
-13:38.047 --> 13:50.596
+00:13:45.480 --> 00:13:50.719
 just using the regular process APIs that Emacs Lisp has. And
 
-13:51.451 --> 13:58.475
+00:13:50.720 --> 00:13:57.119
 that can be, already we, like Guile has some very good
 
-13:51.451 --> 13:58.475
+00:13:57.120 --> 00:14:08.079
 implementations for process management. And so it would
 
-13:59.055 --> 14:05.438
+00:14:08.080 --> 00:14:12.439
 just be a matter of wrapping up those in the Emacs lisp form
 
-13:59.055 --> 14:05.438
+00:14:12.440 --> 00:14:24.919
 bindings. So yeah, dynamic libraries, I wanna try to avoid.
 
-14:12.222 --> 14:20.366
+00:14:24.920 --> 00:14:32.799
 And I would prefer to do things more through, you know,
 
-14:12.222 --> 14:20.366
+00:14:32.800 --> 00:14:40.399
 launching a child process in the Emacs process. and then
 
-14:20.956 --> 14:24.798
+00:14:40.400 --> 00:14:47.239
 communicating over the standard in, standard out
 
-14:20.956 --> 14:24.798
+00:14:47.240 --> 00:14:47.959
 channels.
 
-14:29.460 --> 14:40.386
+00:14:47.960 --> 00:14:52.799
 That's the easier way to do things, I think, because then you
 
-14:29.460 --> 14:40.386
+00:14:52.800 --> 00:14:58.519
 can just use the process library that Emacs already has, and
 
-14:29.460 --> 14:40.386
+00:14:58.520 --> 00:15:03.239
 you can just reuse all of that code.
 
-14:43.969 --> 14:49.912
+00:15:03.240 --> 00:15:09.079
 I'm not sure how ripgrep works, unfortunately, but I
 
-14:43.969 --> 14:49.912
+00:15:09.080 --> 00:15:15.279
 believe that's also a process, a child process. So, we can
 
-14:50.412 --> 14:53.774
+00:15:15.280 --> 00:15:23.479
 just reuse all of the Emacs Lisp code that does that already.
 
-14:54.014 --> 15:05.979
+00:15:23.480 --> 00:15:30.399
 We just need to make sure that the process management
 
-14:54.014 --> 15:05.979
+00:15:30.400 --> 00:15:35.119
 implementation and scheme is properly bound to Emacs Lisp,
 
-14:54.014 --> 15:05.979
+00:15:35.120 --> 00:15:43.359
 and it works the same as GNU Emacs does. Once that's all set,
 
-15:06.360 --> 15:13.383
+00:15:43.360 --> 00:15:48.399
 then these porcelains, like around git, should fall into
 
-15:06.360 --> 15:13.383
+00:15:48.400 --> 00:15:55.279
 place. without too much difficulty, hopefully.
 
 NOTE Q: Not really a question, but how about Schemacs as a name?
 
-15:21.112 --> 15:22.593
+00:15:55.280 --> 00:15:59.199
 How about Schemax as a name? I like the name. I like that name.
 
-15:28.937 --> 15:32.920
+00:15:59.200 --> 00:16:03.119
 I haven't really looked into like, is that already used or is
 
-15:28.937 --> 15:32.920
+00:16:03.120 --> 00:16:09.759
 that going to be confusing? But certainly something we can
 
-15:33.380 --> 15:35.021
+00:16:09.760 --> 00:16:10.959
 discuss.
 
-15:38.243 --> 15:39.264
+00:16:10.960 --> 00:16:13.039
 Another thing I should mention,
 
-15:42.157 --> 15:48.278
+00:16:13.040 --> 00:16:18.759
 I should probably set up a server or something like Discord
 
-15:42.157 --> 15:48.278
+00:16:18.760 --> 00:16:25.359
 or something like that. Discourse, not Discord.
 
-15:51.619 --> 15:56.220
+00:16:25.360 --> 00:16:31.599
 Discourse, the open source one, where we could actually
 
-15:51.619 --> 15:56.220
+00:16:31.600 --> 00:16:49.239
 chat about this stuff. For the time being, ActivityPub,
 
-15:56.540 --> 16:05.562
+00:16:49.240 --> 00:16:52.399
 mostly Mastodon, is how I communicate with people in real
 
-15:56.540 --> 16:05.562
+00:16:52.400 --> 00:16:57.279
 time, that or email. So if you want to get a hold of me, check
 
-16:09.809 --> 16:15.571
+00:16:57.280 --> 00:17:02.439
 the notes for this presentation and just send me an email.
 
-16:16.752 --> 16:18.012
+00:17:02.440 --> 00:17:09.039
 Any question at all is fine. If you want to contribute code,
 
-16:19.633 --> 16:25.495
+00:17:09.040 --> 00:17:12.799
 if you want to just learn how to contribute code, send me any
 
-16:19.633 --> 16:25.495
+00:17:12.800 --> 00:17:22.199
 questions. It's fine. I'm happy to answer them. And we can
 
-16:30.256 --> 16:31.757
+00:17:22.200 --> 00:17:25.879
 talk about the name as well.
 
 NOTE Q: Why is it not feasible for the Emacs layer that interprets Emacs Lisp (the core in C) ot have a Scheme interpreter, instead of using Guile?
 
-16:45.931 --> 16:54.215
+00:17:25.880 --> 00:17:30.239
 Okay, why is it not feasible for the Emacs layer that
 
-16:45.931 --> 16:54.215
+00:17:30.240 --> 00:17:34.319
 interprets Emacs Lisp, the core in C, have a Scheme
 
-16:45.931 --> 16:54.215
+00:17:34.320 --> 00:17:39.799
 interpreter instead of using Guile? Let's see, I have to,
 
-16:55.496 --> 16:57.257
+00:17:39.800 --> 00:17:48.799
 okay. Emacs layer interprets Emacs Lisp, the core in C, have
 
-16:57.737 --> 17:05.942
+00:17:48.800 --> 00:17:54.079
 a Scheme interpreter instead of using Guile. Okay, so that,
 
-17:07.362 --> 17:13.906
+00:17:54.080 --> 00:17:59.959
 the question xlarsx is asking, xlars, x, So Lars is asking,
 
-17:14.744 --> 17:28.093
+00:17:59.960 --> 00:18:02.319
 is it not feasible for there to be an
 
-17:14.744 --> 17:28.093
+00:18:02.320 --> 00:18:06.839
 Emacs layer that interprets Emacs Lisp have a scheme
 
-17:14.744 --> 17:28.093
+00:18:06.840 --> 00:18:33.079
 interpreter? This is Robin Templeton's project. And
 
-17:30.815 --> 17:32.156
+00:18:33.080 --> 00:18:39.839
 they're presenting later today. So check the roster and be
 
-17:32.697 --> 17:41.303
+00:18:39.840 --> 00:18:45.199
 sure to see that presentation because that's exactly what
 
-17:32.697 --> 17:41.303
+00:18:45.200 --> 00:18:52.119
 Robin Templeton is doing. That's not what I'm doing though.
 
-17:44.419 --> 17:46.459
+00:18:52.120 --> 00:18:57.239
 I'm trying to create something in Scheme. But yes, there is
 
-17:48.280 --> 17:54.921
+00:18:57.240 --> 00:19:02.959
 an attempt to get an Scheme interpreter to run inside of
 
-17:48.280 --> 17:54.921
+00:19:02.960 --> 00:19:07.159
 Emacs itself. And it has its own method of binding to Emacs
 
-17:55.181 --> 18:05.323
+00:19:07.160 --> 00:19:11.199
 Lisp functions and translating data like Lisp structures
 
-17:55.181 --> 18:05.323
+00:19:11.200 --> 00:19:14.439
 between Guile Scheme and Emacs Lisp. Robin will explain all
 
-18:05.943 --> 18:08.284
+00:19:14.440 --> 00:19:15.799
 of that in their presentation.
 
-18:28.519 --> 18:33.020
+00:19:15.800 --> 00:19:18.919
 OK, I think I've got through all the questions on Etherpad.
 
-18:33.620 --> 18:35.500
+00:19:18.920 --> 00:19:23.879
 But I'm going to hang out here for a bit longer. And yeah, feel
 
-18:37.621 --> 18:46.182
+00:19:23.880 --> 00:19:28.239
 free to do a video chat with me or send me more questions on
 
-18:37.621 --> 18:46.182
+00:19:28.240 --> 00:19:33.839
 Etherpad or here in the big blue button. And so I'm just going
 
-18:47.002 --> 18:48.082
+00:19:33.840 --> 00:21:49.119
 to hang out. And thanks for asking all your questions. And
 
-18:51.663 --> 18:56.024
+00:21:49.120 --> 00:21:50.839
 yeah, I look forward to working with all of you if you're
 
-18:51.663 --> 18:56.024
+00:21:50.840 --> 00:21:51.799
 interested. take it easy. Thanks so much for the talk and
 
-18:59.935 --> 19:08.180
+00:21:51.800 --> 00:21:53.199
 looking forward to seeing some of your progress as this
 
-18:59.935 --> 19:08.180
+00:21:53.200 --> 00:21:54.359
 moves forward, exciting space. We'll go ahead and leave the
 
-19:09.261 --> 19:14.925
+00:21:54.360 --> 00:21:54.879
 room open for you and thanks for offering to hang out and chat
 
-19:09.261 --> 19:14.925
+00:21:54.880 --> 00:21:55.639
 with other people that come by. Feel free to throw something
 
-19:15.025 --> 19:18.287
+00:21:55.640 --> 00:21:56.719
 in the chat if you want to remind people you're still here.
 
-19:19.557 --> 19:25.143
+00:21:56.720 --> 00:21:57.919
 Meanwhile, on the stream, we have moved along to our next
 
-19:19.557 --> 19:25.143
+00:21:57.920 --> 00:21:59.599
 talk on Rust, and that is just getting started. But again,
 
-19:25.283 --> 19:30.549
+00:21:59.600 --> 00:22:00.479
 we're continuing to record this, and I'll just keep an eye on
 
-19:25.283 --> 19:30.549
+00:22:00.480 --> 00:22:01.239
 it to stop the recording. Thank you. Thank you. It was
 
-19:33.352 --> 19:33.853
+00:22:01.240 --> 00:22:01.559
 awesome.
 
-21:47.935 --> 21:50.558
+00:22:01.560 --> 00:22:03.959
 So it seems like it's slowed down here for the Q&A. I don't see
 
-21:50.638 --> 21:53.741
+00:22:03.960 --> 00:22:05.439
 anybody else on BBB, so I'm going to go ahead and stop the
 
-21:50.638 --> 21:53.741
+00:22:05.440 --> 00:22:08.479
 recording. We can start it back up. I would say, yes, there's
 
-21:55.282 --> 21:58.906
+00:22:08.480 --> 00:22:09.519
 a lot of things you can do with this. You can handle
 
-21:58.926 --> 22:00.627
+00:22:09.520 --> 00:22:11.239
 processing. Yeah, I'm going to try and join over the chat for
 
-22:02.029 --> 22:07.614
+00:22:11.240 --> 00:22:14.679
 the next talk. I'm not sure if I can do both big blue buttons at
 
-22:08.635 --> 22:11.538
+00:22:14.680 --> 00:22:15.759
 the same time. You should be able to just watch your mute
 
-22:13.206 --> 22:19.998
+00:22:15.760 --> 00:22:19.159
 settings and mute tab settings and whatever all you have to
 
-22:13.206 --> 22:19.998
+00:22:19.160 --> 00:23:37.800
 avoid bleed through. Okay.
diff --git a/2024/captions/emacsconf-2024-julia--exploring-shared-philosophies-in-julia-and-emacs--gabriele-bozzola--answers.vtt b/2024/captions/emacsconf-2024-julia--exploring-shared-philosophies-in-julia-and-emacs--gabriele-bozzola--answers.vtt
index d37f80ef..5f0d3fc5 100644
--- a/2024/captions/emacsconf-2024-julia--exploring-shared-philosophies-in-julia-and-emacs--gabriele-bozzola--answers.vtt
+++ b/2024/captions/emacsconf-2024-julia--exploring-shared-philosophies-in-julia-and-emacs--gabriele-bozzola--answers.vtt
@@ -2,345 +2,345 @@ WEBVTT
 
 NOTE Q: Do you have any suggestions for interactive debugging of Julia code in Emacs?
 
-00:00.089 --> 00:00.829
+00:00:00.000 --> 00:00:05.319
 ... answer to that. I, I think the infrastructure for an
 
-00:01.509 --> 00:14.192
+00:00:05.320 --> 00:00:08.599
 ecosystem in Julia in general is as mature as other
 
-00:01.509 --> 00:14.192
+00:00:08.600 --> 00:00:12.559
 languages, and even debugger infiltrator themselves are
 
-00:01.509 --> 00:14.192
+00:00:12.560 --> 00:00:17.519
 not particularly well developed. And so I don't think
 
-00:15.853 --> 00:19.214
+00:00:17.520 --> 00:00:21.519
 there's much we can do about that right now. I think that it's
 
-00:21.570 --> 00:28.057
+00:00:21.520 --> 00:00:25.999
 unfortunate that most of the development for these type of
 
-00:21.570 --> 00:28.057
+00:00:26.000 --> 00:00:31.759
 tools is tightly linked to VS code. But even there, I don't
 
-00:29.218 --> 00:36.225
+00:00:31.760 --> 00:00:35.719
 think that there's much done in terms of interactive
 
-00:29.218 --> 00:36.225
+00:00:35.720 --> 00:00:42.359
 debugging. So I, yeah, I think this has to be worked on mostly
 
-00:36.866 --> 00:43.213
+00:00:42.360 --> 00:00:47.519
 on the Julia side first. And then probably Emacs can get
 
-00:43.820 --> 00:48.303
+00:00:47.520 --> 00:00:51.239
 something out of that. I know that there's development in
 
-00:49.183 --> 00:57.728
+00:00:51.240 --> 00:00:55.559
 debugger.jl itself for future releases to make it at least
 
-00:49.183 --> 00:57.728
+00:00:55.560 --> 00:01:01.839
 faster and more stable. But yeah, I think we're not there as
 
-00:58.809 --> 01:03.852
+00:01:01.840 --> 00:01:06.879
 Julia community itself. So let alone Emacs, integration
 
-01:04.192 --> 01:07.234
+00:01:06.880 --> 00:01:11.239
 with Emacs. The way I personally debug is mostly using,
 
-01:08.286 --> 01:15.508
+00:01:11.240 --> 00:01:15.199
 well, debugger and infiltrator with Julia REPL mode in
 
 NOTE Q: Can you call out something that Julia has that Emacs does not, and which could benefit Emacs?
 
-01:08.286 --> 01:15.508
+00:01:15.200 --> 00:01:21.679
 Emacs. The second question, can you call out something that
 
-01:18.009 --> 01:24.891
+00:01:21.680 --> 00:01:26.839
 Julia has that Emacs does not and which could benefit Emacs?
 
-01:26.852 --> 01:27.852
+00:01:26.840 --> 00:01:31.879
 Nothing stands out to me except the usual multi-threading
 
-01:28.848 --> 01:32.552
+00:01:31.880 --> 00:01:36.119
 and things like this. I don't necessarily see something
 
-01:33.432 --> 01:46.783
+00:01:36.120 --> 00:01:42.479
 that Julia has going on that DMX doesn't have, but I see some
 
-01:33.432 --> 01:46.783
+00:01:42.480 --> 00:01:45.839
 differences and approaches that I think are important,
 
-01:33.432 --> 01:46.783
+00:01:45.840 --> 00:01:49.759
 like the community. I think Julia is a very active and tight
 
-01:47.384 --> 01:50.266
+00:01:49.760 --> 00:01:54.159
 community. Julia uses Slack and is very, very active. I
 
-01:54.093 --> 01:57.736
+00:01:54.160 --> 00:01:56.559
 think he might say something like that, but it's maybe more
 
-01:54.093 --> 01:57.736
+00:01:56.560 --> 00:02:01.799
 on Reddit, IRC. JuliaCon is big and brings together lots and
 
-01:59.078 --> 02:02.381
+00:02:01.800 --> 00:02:05.159
 lots of people. And I think the sense of community is really
 
-02:03.221 --> 02:05.263
+00:02:05.160 --> 00:02:10.479
 powerful. It's very easy to essentially meet people that
 
-02:06.364 --> 02:16.834
+00:02:10.480 --> 00:02:12.919
 are interested in what we're building and interested in
 
-02:06.364 --> 02:16.834
+00:02:12.920 --> 00:02:15.999
 what we're doing and interested in Julian, our, you know,
 
-02:06.364 --> 02:16.834
+00:02:16.000 --> 00:02:21.239
 hacker spirit. I think Emacs is a very strong community.
 
-02:21.228 --> 02:26.151
+00:02:21.240 --> 00:02:24.279
 We're here on a Saturday talking about Emacs, which again
 
-02:21.228 --> 02:26.151
+00:02:24.280 --> 00:02:29.679
 proves that we are doing this. But I'd like to emphasize that
 
-02:27.192 --> 02:35.696
+00:02:29.680 --> 00:02:33.639
 the community is a really important aspect in Julia that I
 
-02:27.192 --> 02:35.696
+00:02:33.640 --> 00:02:38.159
 think we should double down on our side. The next question is
 
 NOTE Q: Is there a way to use lisp syntax with Julia, like hy for python or lisp flavoured erlang?
 
-02:36.797 --> 02:44.841
+00:02:38.160 --> 00:02:46.519
 about Lisp syntax with Julia, like what we can do in Python.
 
-02:48.038 --> 02:53.180
+00:02:46.520 --> 00:02:52.359
 I don't think that's, I don't, I am not aware of any package
 
-02:48.038 --> 02:53.180
+00:02:52.360 --> 00:02:56.879
 that does that. I would bet that there's something there. I
 
-02:56.722 --> 02:58.063
+00:02:56.880 --> 00:03:01.519
 think that that's possible. Indeed, there used to be a Lisp
 
-02:59.243 --> 03:07.027
+00:03:01.520 --> 00:03:08.079
 interpreter in Julia itself until the latest release. The
 
-03:07.647 --> 03:12.229
+00:03:08.080 --> 00:03:12.039
 syntax parsing was done with a Lisp, it was called TemtoList
 
-03:07.647 --> 03:12.229
+00:03:12.040 --> 00:03:18.679
 indeed. I think this got rid, get rid of this for our more
 
-03:16.124 --> 03:23.489
+00:03:18.680 --> 00:03:23.039
 Julia-based solution that is faster and with better code
 
-03:16.124 --> 03:23.489
+00:03:23.040 --> 00:03:28.599
 provenance. I think that it should be possible to use the
 
-03:25.430 --> 03:35.437
+00:03:28.600 --> 00:03:33.319
 metaprogramming features in Julia to change the structure
 
-03:25.430 --> 03:35.437
+00:03:33.320 --> 00:03:38.159
 of your syntax to be a Lispy syntax. I do want to emphasize
 
-03:36.238 --> 00:03:44.664
+00:03:38.160 --> 00:03:43.879
 that Julia is heavily inspired by Lisp, so I wouldn't be
 
-03:36.238 --> 03:44.664
+00:03:43.880 --> 00:03:49.239
 surprised if if something like this were possible.
 
-03:49.309 --> 00:03:51.167
+00:03:49.240 --> 00:03:51.239
 I have tried Julia Snail.
 
 NOTE Q: Have you tried the Julia Snail package for Emacs? It tries to be like SLY/SLIME for Common Lisp.
 
-00:03:51.168 --> 00:03:51.070
+00:03:51.240 --> 00:03:54.399
 So the next question is about Julia
 
-03:51.270 --> 03:52.712
+00:03:54.400 --> 00:03:58.199
 Snail. I found Julia REPL to be a little bit easier to set up
 
-03:53.312 --> 03:58.436
+00:03:58.200 --> 00:04:02.839
 and use. So I just settled on that. I should maybe revisit
 
-04:00.918 --> 04:03.480
+00:04:02.840 --> 00:04:05.999
 that. In particular, I use the Julia REPL with the vterm
 
-04:03.720 --> 04:11.406
+00:04:06.000 --> 00:04:10.959
 backend, which essentially makes a companion REPL to my
 
-04:03.720 --> 04:11.406
+00:04:10.960 --> 00:04:15.439
 scripts. And that works for me. I do think that the tooling
 
-04:15.638 --> 04:16.518
+00:04:15.440 --> 00:04:19.239
 uh, could be improved. I think there is definitely much room
 
-04:17.399 --> 04:22.040
+00:04:19.240 --> 00:04:26.079
 and I would like to see improvement in that area. Um, and, uh,
 
 NOTE Q: Is there a data inspector for a Julia REPL available that you can use in Emacs?
 
-04:22.940 --> 04:28.322
+00:04:26.080 --> 00:04:31.639
 so we have data inspector for Julia REPL.
 
-04:32.043 --> 04:34.784
+00:04:31.640 --> 00:04:37.279
 I don't think so. I don't, is there any data inspector
 
-04:34.804 --> 04:39.826
+00:04:37.280 --> 00:04:40.439
 in for, for the Julia REPL that we can use in Emacs?
 
-04:43.223 --> 00:04:43.489
+00:04:40.440 --> 00:04:44.839
 I'm not sure. I don't think so.
 
-00:04:44.840 --> 00:04:47.839
+00:04:44.840 --> 00:04:47.799
 I think the way I look at data is
 
-00:04:47.840 --> 00:04:50.519
+00:04:47.800 --> 00:04:50.519
 essentially ignoring Emacs when encoded. It's just using the
 
-00:04:50.520 --> 00:04:54.759
+00:04:50.520 --> 00:04:56.839
 REPL. And again, with Julia REPL. So I'm not aware of any
 
-00:04:54.760 --> 00:04:57.720
+00:04:56.840 --> 00:05:00.479
 specialized tool And again, maybe this is, again, a good
 
-04:58.652 --> 05:05.595
+00:05:00.480 --> 00:05:04.279
 moment to emphasize that tooling, the Julia community
 
-04:58.652 --> 05:05.595
+00:05:04.280 --> 00:05:09.079
 clusters around VS Code. And there is tools like the, pretty
 
-05:06.315 --> 05:11.578
+00:05:09.080 --> 00:05:14.199
 much all the work with VS Code, unfortunately. And while
 
-05:12.578 --> 05:21.242
+00:05:14.200 --> 00:05:17.759
 there's a very, very decent Julia mode and Julia repo mode
 
-05:12.578 --> 05:21.242
+00:05:17.760 --> 00:05:21.439
 and Julia snail, there's definitely, definitely room for
 
-05:12.578 --> 05:21.242
+00:05:21.440 --> 00:05:24.359
 improvement.
 
 NOTE Q: Have you tried literate programming Julia (using Org babel or some other means) in Emacs?
 
-05:24.443 --> 05:28.145
+00:05:24.360 --> 00:05:27.759
 Next, we have a question about literate programming in
 
-05:24.443 --> 05:28.145
+00:05:27.760 --> 00:05:32.439
 Julia. I haven't done much of it with Org Babel or
 
-05:29.505 --> 05:32.906
+00:05:32.440 --> 00:05:37.079
 anything else. I haven't done much of it. I can say that Julia
 
-05:35.827 --> 05:46.070
+00:05:37.080 --> 00:05:40.719
 has developed a new iteration of notebooks called Pluto.
 
-05:46.090 --> 05:48.471
+00:05:40.720 --> 00:05:47.119
 Here I'm thinking about Jupyter notebooks. The Pluto
 
-05:51.021 --> 06:02.988
+00:05:47.120 --> 00:05:55.359
 notebooks for Julia try to remove a bunch of the pain points
 
-05:51.021 --> 06:02.988
+00:05:55.360 --> 00:06:00.439
 that Jupyter notebooks have, meaning you cannot easily
 
-05:51.021 --> 06:02.988
+00:06:00.440 --> 00:06:03.639
 commit them to Git or things like this.
 
-06:06.450 --> 06:09.152
+00:06:03.640 --> 00:06:09.279
 I haven't used them, but I know some people are very fond of
 
-06:06.450 --> 06:09.152
+00:06:09.280 --> 00:06:13.559
 them. And so I think that that's what some of the Julia
 
-06:09.872 --> 06:15.195
+00:06:13.560 --> 00:06:16.879
 community would use for notebooks. And I think they can
 
-06:15.315 --> 06:19.298
+00:06:16.880 --> 00:06:22.239
 interact with Emacs with no problem. And that would be a form
 
-06:20.974 --> 06:23.035
+00:06:22.240 --> 00:06:26.879
 of later programming. But if you can do it in Python, you can
 
-06:24.015 --> 06:27.696
+00:06:26.880 --> 00:06:32.119
 do it in Julia. I think there is no reason. And actually, you
 
-06:30.617 --> 06:38.719
+00:06:32.120 --> 00:06:35.839
 can take advantage of all this just-in-time or
 
-06:30.617 --> 06:38.719
+00:06:35.840 --> 00:06:38.239
 just-out-of-time compilation by keeping the same
 
-06:30.617 --> 06:38.719
+00:06:38.240 --> 00:06:45.199
 session. So I think it will be definitely a nice use case. So
 
-06:44.681 --> 06:47.222
+00:06:45.200 --> 00:06:49.199
 these are the questions that I see here. I'm going to scroll
 
-06:48.561 --> 06:54.486
+00:06:49.200 --> 00:06:52.759
 through the comments and see if there's something that I
 
-06:48.561 --> 06:54.486
+00:06:52.760 --> 00:06:57.319
 should say about comments. I'm excited people want to learn
 
-06:56.228 --> 06:57.669
+00:06:57.320 --> 00:07:02.519
 Julia. I have to say that if I want to do GPU computing
 
-06:58.990 --> 07:06.757
+00:07:02.520 --> 00:07:06.399
 nowadays, I find it much easier to do it with Julia than with
 
-06:58.990 --> 07:06.757
+00:07:06.400 --> 00:07:11.759
 CUDA. So I encourage people to look into that. And I do,
 
-07:11.758 --> 07:26.807
+00:07:11.760 --> 00:07:19.359
 again, I would like to share what makes me excited about
 
-07:11.758 --> 07:26.807
+00:07:19.360 --> 00:07:23.799
 Emacs, about this being open, being collaborative, being
 
-07:11.758 --> 07:26.807
+00:07:23.800 --> 00:07:26.399
 respectable with documentation is something that I find in
 
-07:11.758 --> 07:26.807
+00:07:26.400 --> 00:07:30.999
 Julia. So I think people that are excited about the same
 
-07:27.367 --> 07:35.192
+00:07:31.000 --> 00:07:35.279
 features will find a little bit of joy in working with Julia.
 
-07:38.214 --> 07:39.675
+00:07:35.280 --> 00:07:41.999
 I think I addressed what I have here. I don't know if there's
 
-07:40.189 --> 07:43.532
+00:07:42.000 --> 00:07:43.559
 anything else that I should add.
 
-07:51.718 --> 07:54.000
+00:07:43.560 --> 00:07:52.879
 It took me a minute to unmute there.
 
-00:07:54.040 --> 00:07:58.399
+00:07:52.880 --> 00:07:57.519
 No, I think that was awesome. And thank you so much.
 
-00:07:58.400 --> 00:08:00.399
+00:07:57.520 --> 00:08:00.119
 I guess I thought it would
 
-00:08:00.400 --> 00:08:06.559
+00:08:00.120 --> 00:08:06.279
 collapse that shared area on BBB, my mistake, on the stream,
 
-00:08:06.560 --> 00:08:12.399
+00:08:06.280 --> 00:08:12.359
 or I would have left it open. But in any case, no, I thought
 
-00:08:12.400 --> 00:08:15.079
+00:08:12.360 --> 00:08:15.079
 that was great. You did a great job of responding to all the
 
-00:08:15.080 --> 00:08:17.879
+00:08:15.080 --> 00:08:17.839
 questions and comments. And thank you again so much for your
 
-00:08:17.880 --> 00:08:20.920
+00:08:17.840 --> 00:08:23.199
 talk and getting us all excited to learn Julia. Thank you.
 
-08:24.094 --> 08:25.275
+00:08:23.200 --> 00:08:27.759
 Enjoy EmacsConf. And again, thanks so much for attending,
 
-08:25.335 --> 08:30.220
+00:08:27.760 --> 00:08:42.400
 for being EmacsConf. Thank you.
diff --git a/2024/captions/emacsconf-2024-transducers--transducers-finally-ergonomic-data-processing-for-emacs--colin-woodbury--answers.vtt b/2024/captions/emacsconf-2024-transducers--transducers-finally-ergonomic-data-processing-for-emacs--colin-woodbury--answers.vtt
index 375cad2a..e8cb84c4 100644
--- a/2024/captions/emacsconf-2024-transducers--transducers-finally-ergonomic-data-processing-for-emacs--colin-woodbury--answers.vtt
+++ b/2024/captions/emacsconf-2024-transducers--transducers-finally-ergonomic-data-processing-for-emacs--colin-woodbury--answers.vtt
@@ -10,7 +10,7 @@ morning here in Tokyo.
 Are we connected all right?
 
 00:00:37.880 --> 00:00:40.879
-Okay, I seem to be struggling still with my audio. 1 2nd
+Okay, I seem to be struggling still with my audio. One second...
 
 00:00:40.880 --> 00:00:44.519
 calling. Yeah, you were muted for a moment there. Okay,