diff options
Diffstat (limited to '2024/captions')
7 files changed, 1056 insertions, 1055 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-emacs30--emacs-30-highlights--philip-kaludercic--main--chapters.vtt b/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main--chapters.vtt index 89190453..57ef14d3 100644 --- a/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main--chapters.vtt +++ b/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main--chapters.vtt @@ -1,35 +1,35 @@ WEBVTT -00:00:00.000 --> 00:01:41.800 +00:00:00.000 --> 00:01:41.759 Introduction -00:01:41.800 --> 00:07:45.719 +00:01:41.760 --> 00:07:44.699 Android -00:07:45.720 --> 00:09:27.320 +00:07:44.700 --> 00:09:30.239 EditorConfig -00:09:27.310 --> 00:13:11.559 +00:09:30.240 --> 00:13:11.399 use-package integration with package-vc -00:13:11.560 --> 00:15:56.679 +00:13:11.400 --> 00:15:56.839 JSON -00:15:56.680 --> 00:17:29.639 +00:15:56.840 --> 00:17:30.719 Native compilation -00:17:29.640 --> 00:18:16.779 +00:17:30.720 --> 00:18:16.819 Tree-sitter -00:18:16.780 --> 00:19:34.200 +00:18:16.820 --> 00:19:34.219 Completion preview mode -00:19:34.233 --> 00:21:16.919 +00:19:34.220 --> 00:21:16.779 package-isolate -00:21:16.920 --> 00:23:17.939 +00:21:16.780 --> 00:23:17.879 Reindenting -00:23:17.940 --> 00:24:43.766 +00:23:17.880 --> 00:24:43.120 Wrapping up diff --git a/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main.vtt b/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main.vtt index f0d08f0b..feebc2ed 100644 --- a/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main.vtt +++ b/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main.vtt @@ -1,1361 +1,1361 @@ -WEBVTT captioned by anush and sachac, checked by anush and bhavin +WEBVTT captioned by anush NOTE Introduction -00:00.000 --> 00:06.066 +00:00:00.000 --> 00:00:06.119 Hello, and welcome to Emacs 30 Highlights at EmacsConf 2024. -00:06.100 --> 00:08.833 +00:00:06.120 --> 00:00:08.839 Before I begin, I'd like to thank the organizers -00:08.866 --> 00:11.800 +00:00:08.840 --> 00:00:11.799 and everyone involved for putting this all together. -00:11.800 --> 00:13.733 +00:00:11.800 --> 00:00:13.759 While this talk is being pre-recorded, -00:13.766 --> 00:15.233 +00:00:13.760 --> 00:00:15.239 my experience from the last few years -00:15.266 --> 00:19.100 +00:00:15.240 --> 00:00:19.159 assures me that it will be a great experience for everyone. -00:19.133 --> 00:21.300 +00:00:19.160 --> 00:00:21.359 My name is Philip Kaludercic. -00:21.333 --> 00:24.466 +00:00:21.360 --> 00:00:24.479 I am a core contributor and ELPA co-maintainer. -00:24.500 --> 00:26.066 +00:00:24.480 --> 00:00:26.079 I was honored when Sacha asked me -00:26.100 --> 00:28.333 +00:00:26.080 --> 00:00:28.359 to take over the slot for this year. -00:28.366 --> 00:29.866 +00:00:28.360 --> 00:00:29.879 In the past few iterations, -00:29.900 --> 00:32.133 +00:00:29.880 --> 00:00:32.199 John Wiegley has filled a similar presentation -00:32.166 --> 00:35.666 +00:00:32.200 --> 00:00:35.679 focusing on more general Emacs development updates. -00:35.700 --> 00:00:38.501 +00:00:35.680 --> 00:00:38.519 This year, I will specifically focus on -00:00:38.502 --> 00:00:41.900 +00:00:38.520 --> 00:00:41.919 highlight features from the upcoming Emacs 30 release, -00:41.933 --> 00:44.200 +00:00:41.920 --> 00:00:43.919 which might or might not have been released -00:44.200 --> 00:00:48.059 +00:00:43.920 --> 00:00:48.079 by the time you are seeing this. -00:00:48.060 --> 00:51.266 +00:00:48.080 --> 00:00:51.079 As you can imagine, everything new about Emacs -00:51.300 --> 00:55.133 +00:00:51.080 --> 00:00:55.059 can always be found in the Emacs NEWS file. -00:55.166 --> 00:57.100 +00:00:55.060 --> 00:00:57.079 Or, alternatively, -00:57.133 --> 01:01.800 +00:00:57.080 --> 00:01:01.919 if one doesn't want to read through the 3,000 lines here, -01:01.800 --> 01:05.233 +00:01:01.920 --> 00:01:05.279 one can also take a look at the Emacs FAQ -01:05.266 --> 01:08.000 +00:01:05.280 --> 00:01:07.999 and then go to the what's new about -01:08.000 --> 01:12.300 +00:01:08.000 --> 00:01:12.219 or what's different about Emacs 30 node. -01:12.333 --> 01:14.700 +00:01:12.220 --> 00:01:14.759 Next to these two official options, -01:14.733 --> 01:18.200 +00:01:14.760 --> 00:01:18.599 I also have a page on Emacs Wiki -01:18.200 --> 01:21.300 +00:01:18.600 --> 00:01:21.439 called EmacsThirtyHighlights, -01:21.333 --> 01:24.266 +00:01:21.440 --> 00:01:24.279 highlighting some of the interesting features -01:24.300 --> 01:28.433 +00:01:24.280 --> 00:01:28.439 with some context and suggestions on how to try them out. -01:28.466 --> 01:30.033 +00:01:28.440 --> 00:01:30.039 This is more of a collaborative effort. -01:30.066 --> 01:32.733 +00:01:30.040 --> 00:01:32.719 So if you see this and think something is missing, -01:32.766 --> 01:34.500 +00:01:32.720 --> 00:01:34.519 feel free to add it. -01:34.533 --> 01:36.833 +00:01:34.520 --> 00:01:36.839 So without further ado, -01:36.866 --> 01:41.800 +00:01:36.840 --> 00:01:41.759 let's begin taking a look at new features in Emacs 30. NOTE Android -01:41.800 --> 01:44.700 +00:01:41.760 --> 00:01:44.679 The biggest one, and the one I want to mention first, -01:44.733 --> 01:49.033 +00:01:44.680 --> 00:01:49.039 is Android support, native Android support. -01:49.066 --> 01:51.833 +00:01:49.040 --> 00:01:51.879 As you can see here, Emacs has been ported -01:51.866 --> 01:53.666 +00:01:51.880 --> 00:01:53.639 to the Android operating system. -01:53.700 --> 01:56.500 +00:01:53.640 --> 00:01:56.479 What this means is that from Emacs 30 onwards, -01:56.533 --> 02:01.066 +00:01:56.480 --> 00:02:01.279 you can build Android to target Android devices natively -02:01.100 --> 02:06.733 +00:02:01.280 --> 00:02:06.759 and using a graphical interface. -02:06.766 --> 02:08.433 +00:02:06.760 --> 00:02:08.799 While it has been possible to run Emacs -02:08.466 --> 02:11.133 +00:02:08.800 --> 00:02:11.159 inside of terminal emulators on Android for a while, -02:11.166 --> 02:13.900 +00:02:11.160 --> 00:02:13.919 this actually means that you can use Emacs -02:13.933 --> 02:17.533 +00:02:13.920 --> 00:02:17.519 on an Android device, a phone or a tablet, -02:17.566 --> 02:20.933 +00:02:17.520 --> 00:02:20.959 and have all the usual advantages from GUI Emacs, -02:20.966 --> 02:23.466 +00:02:20.960 --> 00:02:23.479 such as the ability to bind all commands -02:23.500 --> 02:25.466 +00:02:23.480 --> 00:02:25.479 without having to worry about-- -02:25.500 --> 02:27.266 +00:02:25.480 --> 00:02:27.279 all keys without having to worry -02:27.300 --> 02:29.033 +00:02:27.280 --> 00:02:29.359 about terminal compatibility issues, -02:29.066 --> 02:32.733 +00:02:29.360 --> 00:02:32.759 displaying images and multiple fonts -02:32.766 --> 02:35.333 +00:02:32.760 --> 00:02:35.359 on the same display of different sizes. -02:35.366 --> 02:37.300 +00:02:35.360 --> 00:02:37.279 I should have a recording -02:37.333 --> 02:42.200 +00:02:37.280 --> 00:02:42.199 of that somewhere here--here we are-- -02:42.200 --> 02:44.100 +00:02:42.200 --> 00:02:44.439 which I made earlier on my phone, -02:44.133 --> 02:47.266 +00:02:44.440 --> 00:02:47.319 because I'm recording this on a laptop-- -02:47.300 --> 02:50.466 +00:02:47.320 --> 00:02:50.479 where we can see how touch interaction works -02:50.500 --> 02:53.333 +00:02:50.480 --> 00:02:53.199 on an Android phone. I can switch between buffers. -02:53.366 --> 02:56.100 +00:02:53.200 --> 00:02:56.119 Here I've connected an external keyboard, -02:56.133 --> 02:57.800 +00:02:56.120 --> 00:02:58.559 opening the Emacs website. -02:57.800 --> 00:03:02.559 +00:02:58.560 --> 00:03:02.679 We have images that we can interact with. -00:03:02.560 --> 00:03:04.319 +00:03:02.680 --> 00:03:05.319 We could resize them if we wanted to -00:03:04.320 --> 03:07.400 +00:03:05.320 --> 00:03:07.559 with the image resizing commands. -03:07.400 --> 03:10.300 +00:03:07.560 --> 00:03:10.359 Pinch-to-zoom works, so it -03:10.333 --> 03:12.733 +00:03:10.360 --> 00:03:12.759 does realize what touchscreen interactions are. -03:12.766 --> 03:15.233 +00:03:12.760 --> 00:03:15.239 With an external mouse, and for example, -03:15.266 --> 03:17.800 +00:03:15.240 --> 00:03:17.799 enabling context menu mode, -03:17.800 --> 03:23.066 +00:03:17.800 --> 00:03:22.679 I can even pop up little interaction windows, -03:23.100 --> 00:03:28.139 +00:03:22.680 --> 00:03:27.239 which one you would usually also know from GUI Emacs. -00:03:28.140 --> 03:33.200 +00:03:27.240 --> 00:03:32.959 TUI Emacs actually also supports them since a while now. -03:33.200 --> 03:34.600 +00:03:32.960 --> 00:03:34.639 And in this case, I'm demonstrating -03:34.600 --> 03:36.000 +00:03:34.640 --> 00:03:35.999 how even the touchscreen events -03:36.000 --> 03:39.133 +00:03:36.000 --> 00:03:39.119 can be inspected using the usual help system, -03:39.166 --> 03:43.333 +00:03:39.120 --> 00:03:43.359 and how context-mode notices -03:43.366 --> 03:45.200 +00:03:43.360 --> 00:03:45.239 where we are and allows me to, for example, -03:45.200 --> 03:47.800 +00:03:45.240 --> 00:03:47.799 evaluate this specific region, -03:47.800 --> 03:49.300 +00:03:47.800 --> 00:03:49.079 which I've highlighted down there, -03:49.333 --> 03:58.300 +00:03:49.080 --> 00:03:58.319 binding a command to touch-screen-scroll. Yeah. -03:58.333 --> 04:00.533 +00:03:58.320 --> 00:04:00.479 One should note that these additions, -04:00.566 --> 04:02.400 +00:04:00.480 --> 00:04:02.359 for example touchscreen interaction, -04:02.400 --> 04:03.833 +00:04:02.360 --> 00:04:04.159 are not specific to Android, -04:03.866 --> 04:07.066 +00:04:04.160 --> 00:04:06.839 but they also are supported in other operating systems, -04:07.100 --> 04:12.200 +00:04:06.840 --> 00:04:12.279 such as Wayland and Xorg, which are not operating systems, -04:12.200 --> 04:15.300 +00:04:12.280 --> 00:04:15.279 and Windows, insofar as they have touchscreen, -04:15.333 --> 00:04:18.419 +00:04:15.280 --> 00:04:18.419 and devices have touchscreen support. -00:04:18.420 --> 04:21.300 +00:04:18.420 --> 00:04:21.239 One should mention, or I want to mention, -04:21.333 --> 04:24.666 +00:04:21.240 --> 00:04:24.039 that the main developer behind this feature, Po Lu, -04:24.700 --> 04:27.500 +00:04:24.040 --> 00:04:27.319 should be complimented for the additional effort he put -04:27.533 --> 00:04:31.019 +00:04:27.320 --> 00:04:30.979 into making sure that Emacs for Android -00:04:31.020 --> 04:34.133 +00:04:30.980 --> 00:04:33.719 can be built using only a free software toolchain, -04:34.166 --> 00:04:36.359 +00:04:33.720 --> 00:04:36.999 which is certainly not something one has come to expect -00:04:36.360 --> 04:40.700 +00:04:37.000 --> 00:04:40.759 from working on Android applications, -04:40.733 --> 04:43.833 +00:04:40.760 --> 00:04:43.839 as usually you have to agree to some terms and conditions -04:43.866 --> 00:04:46.519 +00:04:43.840 --> 00:04:46.479 for Google-specific software. -00:04:46.520 --> 04:49.633 +00:04:46.480 --> 00:04:49.639 Final note is that if you try and look for this online, -04:49.666 --> 04:52.133 +00:04:49.640 --> 00:04:52.119 there are APKs you can find, -04:52.166 --> 04:54.666 +00:04:52.120 --> 00:04:54.679 but some of them might be outdated. -04:54.700 --> 04:59.333 +00:04:54.680 --> 00:04:59.359 To the best of my knowledge, Po Lu has... -04:59.366 --> 05:03.400 +00:04:59.360 --> 00:05:02.399 Emacs 30 Android Sourceforge... -05:03.400 --> 05:06.500 +00:05:02.400 --> 00:05:06.759 He has set up some system where here in Sourceforge, -05:06.533 --> 05:12.433 +00:05:06.760 --> 00:05:12.799 there are regular and updated -05:12.466 --> 05:14.500 +00:05:12.800 --> 00:05:14.519 APK files which you can download -05:14.533 --> 05:16.933 +00:05:14.520 --> 00:05:17.039 to avoid having to build it yourself, -05:16.966 --> 05:18.866 +00:05:17.040 --> 00:05:18.559 testing out the newest version -05:18.900 --> 05:24.133 +00:05:18.560 --> 00:05:27.619 in case there are some bugs which you'd like to report. -05:24.166 --> 05:33.100 +00:05:27.620 --> 00:05:33.119 Which-key is a package which has now been moved -05:33.133 --> 05:35.266 +00:05:33.120 --> 00:05:34.719 from ELPA to the core. -05:35.300 --> 00:05:39.179 +00:05:34.720 --> 00:05:38.879 If you haven't heard of which-key before, the idea is, -00:05:39.180 --> 05:41.633 +00:05:38.880 --> 00:05:41.399 or the general pitch is that which-key -05:41.666 --> 05:45.233 +00:05:41.400 --> 00:05:45.279 is a additional documentation interface for Emacs -05:45.266 --> 05:49.700 +00:05:45.280 --> 00:05:49.639 for displaying various keys which you could input, -05:49.733 --> 00:05:53.439 +00:05:49.640 --> 00:05:53.479 or various keys and key maps -00:05:53.440 --> 05:54.833 +00:05:53.480 --> 00:05:55.479 that have been partially inputted. -05:54.866 --> 05:57.633 +00:05:55.480 --> 00:05:57.639 A better way to demonstrate this -05:57.666 --> 05:59.300 +00:05:57.640 --> 00:05:59.319 or to explain this is just to show it. -05:59.333 --> 06:03.466 +00:05:59.320 --> 00:06:03.519 If we enable the which-key mode--it's a global minor mode-- -06:03.500 --> 06:06.333 +00:06:03.520 --> 00:06:06.399 then I can press, for example, C-x, -06:06.366 --> 06:08.700 +00:06:06.400 --> 00:06:08.719 which is a prefix for the C-x keymap. -06:08.733 --> 06:12.433 +00:06:08.720 --> 00:06:11.719 Then down here in the buffer, in this window down here, -06:12.466 --> 06:15.333 +00:06:11.720 --> 00:06:15.599 we see various commands which we could invoke -06:15.366 --> 06:17.900 +00:06:15.600 --> 00:06:17.919 and the keys to invoke them with. -06:17.933 --> 06:23.000 +00:06:17.920 --> 00:06:23.039 For example, if I wanted to say C-x i for insert-file, -06:23.000 --> 06:27.233 +00:06:23.040 --> 00:06:27.319 then I just have to press i to highlight it once again. -06:27.266 --> 06:32.600 +00:06:27.320 --> 00:06:32.559 It should be down here. Pressing i without having to repeat -06:32.600 --> 06:34.733 +00:06:32.560 --> 00:06:34.759 the entire key code again, -06:34.766 --> 06:37.200 +00:06:34.760 --> 00:06:37.719 the partial key code again, just works. -06:37.200 --> 06:41.533 +00:06:37.720 --> 00:06:41.679 This is different from the feature which Emacs has already, -06:41.566 --> 06:45.400 +00:06:41.680 --> 00:06:45.519 which is if you have input the partial keychord, -06:45.400 --> 06:47.033 +00:06:45.520 --> 00:06:47.039 you can press C-h -06:47.066 --> 06:51.000 +00:06:47.040 --> 00:06:50.959 and then a help buffer pops up with a listing -06:51.000 --> 06:54.066 +00:06:50.960 --> 00:06:54.159 of all keybindings that start with C-x. -06:54.100 --> 06:56.633 +00:06:54.160 --> 00:06:56.639 The information is the same, the presentation is different, -06:56.666 --> 06:59.066 +00:06:56.640 --> 00:06:59.159 because now if I wanted to do C-x i, -06:59.100 --> 00:07:03.339 +00:06:59.160 --> 00:07:03.319 I have to repeat the entire keychord again. -00:07:03.340 --> 07:09.466 +00:07:03.320 --> 00:07:09.479 So it's a matter of personal preference, which you prefer. -07:09.500 --> 00:07:10.959 +00:07:09.480 --> 00:07:12.519 This is more of a traditional static approach -00:07:10.960 --> 07:19.633 +00:07:12.520 --> 00:07:19.639 because I get a help buffer which I can search -07:19.666 --> 07:20.900 +00:07:19.640 --> 00:07:21.119 using usual key commands, -07:20.933 --> 07:28.133 +00:07:21.120 --> 00:07:28.159 while which-key is more of a transient and modern. -07:28.166 --> 07:31.400 +00:07:28.160 --> 00:07:31.299 Some might prefer that approach -07:31.400 --> 00:07:35.719 +00:07:31.300 --> 00:07:35.519 to solving the same problem. -00:07:35.720 --> 07:39.100 +00:07:35.520 --> 00:07:39.119 Also, don't forget to check out the customization group -07:39.133 --> 07:41.933 +00:07:39.120 --> 00:07:41.959 for which-key which has a number of options -07:41.966 --> 00:07:45.719 +00:07:41.960 --> 00:07:44.699 which you might or might not be interested in. NOTE EditorConfig -00:07:45.720 --> 07:50.866 +00:07:44.700 --> 00:07:50.879 Next up, Emacs 30 has built-in EditorConfig support. -07:50.900 --> 07:53.633 +00:07:50.880 --> 00:07:53.679 If you have not heard of EditorConfig before, -07:53.666 --> 00:07:56.639 +00:07:53.680 --> 00:07:56.379 I believe I've linked to it down here somewhere. -00:07:56.640 --> 00:08:00.119 +00:07:56.380 --> 00:08:00.160 Ah, there it is, EditorConfig. -00:08:00.120 --> 00:08:09.419 +00:08:00.161 --> 00:08:05.260 This is a file format used to specify -00:08:09.420 --> 08:12.133 +00:08:05.261 --> 00:08:11.959 common formatting rules in an editor-agnostic way. -08:12.166 --> 08:16.266 +00:08:11.960 --> 00:08:16.319 You might compare it to .dir-locals.el files, -08:16.300 --> 08:19.333 +00:08:16.320 --> 00:08:19.159 which is a sort of an s-expression -08:19.366 --> 08:22.233 +00:08:19.160 --> 00:08:22.159 for setting file-local variables in Emacs. -08:22.266 --> 08:27.266 +00:08:22.160 --> 00:08:26.559 Of course, this is restricted to the common subset -08:27.300 --> 08:29.400 +00:08:26.560 --> 00:08:29.299 of what all editors should understand. -08:29.400 --> 08:31.833 +00:08:29.300 --> 00:08:31.839 For example, indentation styles, -08:31.866 --> 00:08:35.119 +00:08:31.840 --> 00:08:36.699 whether you prefer tabs or spaces, -00:08:35.120 --> 08:38.733 +00:08:36.700 --> 00:08:38.759 tab width, file encoding, and so on. -08:38.766 --> 00:08:43.919 +00:08:38.760 --> 00:08:43.959 So it's nothing too advanced, but it's something... -00:08:43.920 --> 08:48.500 +00:08:43.960 --> 00:08:48.559 It is a file format which one sees popping up more -08:48.533 --> 08:50.433 +00:08:48.560 --> 00:08:50.439 and more often in lots of projects -08:50.466 --> 08:53.600 +00:08:50.440 --> 00:08:53.479 which want to enforce a consistent indentation style -08:53.600 --> 08:56.633 +00:08:53.480 --> 00:08:56.639 or formatting rules for all editors in a project. -08:56.666 --> 09:00.200 +00:08:56.640 --> 00:09:00.159 Having this built in is certainly useful in Emacs. -09:00.200 --> 09:03.466 +00:09:00.160 --> 00:09:03.579 Though one should note that it's not enabled by default. -09:03.500 --> 00:09:10.939 +00:09:03.580 --> 00:09:11.039 You still have to enable the global minor mode, -00:09:10.940 --> 09:14.200 +00:09:11.040 --> 00:09:14.239 which is simply turning on this one option. -09:14.200 --> 09:15.500 +00:09:14.240 --> 00:09:15.599 Shouldn't be more than that, -09:15.533 --> 09:18.633 +00:09:15.600 --> 00:09:18.759 and then Emacs will respect the rules. -09:18.666 --> 00:09:23.640 +00:09:18.760 --> 00:09:22.999 If it finds a .editorconfig file in the project directory, -00:09:23.641 --> 00:09:25.320 +00:09:23.000 --> 00:09:25.319 then it will respect those rules -00:09:25.321 --> 00:09:27.320 +00:09:25.320 --> 00:09:30.239 without having to do anything else. NOTE use-package integration with package-vc -00:09:27.310 --> 00:09:33.567 +00:09:30.240 --> 00:09:34.599 Next up, use-package integration with package-vc. -00:09:33.568 --> 00:09:36.533 +00:09:34.600 --> 00:09:36.519 For those not familiar with either of the two, -00:09:36.534 --> 00:09:37.533 +00:09:36.520 --> 00:09:38.119 or at least one of the two, -00:09:37.534 --> 00:09:40.699 +00:09:38.120 --> 00:09:41.079 use-package is a popular configuration macro. -00:09:40.700 --> 00:09:42.833 +00:09:41.080 --> 00:09:43.119 What it does is it allows -00:09:42.866 --> 00:09:46.233 +00:09:43.120 --> 00:09:46.274 users to declaratively specify packages -00:09:46.266 --> 00:09:48.900 +00:09:46.275 --> 00:09:48.879 they would like to have installed and configured -00:09:48.900 --> 00:09:51.659 +00:09:48.880 --> 00:09:51.539 in their configuration file, -00:09:51.660 --> 00:09:54.400 +00:09:51.540 --> 00:09:54.359 so that, for example, if you copy your init.el -00:09:54.433 --> 00:09:55.900 +00:09:54.360 --> 00:09:55.959 from one system to another, -00:09:55.900 --> 00:09:58.500 +00:09:55.960 --> 00:09:58.519 it could bootstrap the entire configuration, -00:09:58.500 --> 00:10:00.733 +00:09:58.520 --> 00:10:00.719 downloading all the packages you want -00:10:00.766 --> 00:10:02.366 +00:10:00.720 --> 00:10:02.239 without having to manually do this -00:10:02.400 --> 00:10:05.139 +00:10:02.240 --> 00:10:05.039 on every system you'd like to use. -00:10:05.140 --> 00:10:07.600 +00:10:05.040 --> 00:10:07.559 This allows configurations -00:10:07.633 --> 00:10:10.859 +00:10:07.560 --> 00:10:11.039 to be self-encapsulated and portable. -00:10:10.860 --> 00:10:15.059 +00:10:11.040 --> 00:10:15.959 package-vc is an extension of package.el, -00:10:15.060 --> 00:10:19.400 +00:10:15.960 --> 00:10:19.679 which allows installing packages from an alternative. -00:10:19.433 --> 00:10:22.366 +00:10:19.680 --> 00:10:22.279 Instead of using the standard way to install packages, -00:10:22.400 --> 00:10:26.499 +00:10:22.280 --> 00:10:26.239 which is just download tarball and unpack it, -00:10:26.500 --> 00:10:27.933 +00:10:26.240 --> 00:10:28.359 byte compile, and so on, -00:10:27.966 --> 00:10:32.399 +00:10:28.360 --> 00:10:32.759 it will fetch the files for a package -00:10:32.400 --> 00:10:34.966 +00:10:32.760 --> 00:10:35.279 directly from the source code repository -00:10:35.000 --> 00:10:37.233 +00:10:35.280 --> 00:10:37.239 and initialize it in such a way -00:10:37.266 --> 00:10:38.800 +00:10:37.240 --> 00:10:39.119 that package.el can work with it. -00:10:38.833 --> 00:10:44.239 +00:10:39.120 --> 00:10:44.319 So it's just a front-end for installing packages. -00:10:44.240 --> 00:10:46.500 +00:10:44.320 --> 00:10:46.519 Even though these two were added to Emacs 29, -00:10:46.500 --> 00:10:48.366 +00:10:46.520 --> 00:10:48.399 we didn't have the time to work on the -00:10:48.400 --> 00:10:52.500 +00:10:48.400 --> 00:10:52.639 use-package integration of package-vc into use-package, -00:10:52.500 --> 00:10:54.600 +00:10:52.640 --> 00:10:55.359 which has been changed now. -00:10:54.633 --> 00:11:00.139 +00:10:55.360 --> 00:11:00.119 What we have with Emacs 30 is that -00:11:00.140 --> 00:11:02.833 +00:11:00.120 --> 00:11:02.839 there is a :vc keyword for use-package -00:11:02.866 --> 00:11:05.200 +00:11:02.840 --> 00:11:05.319 with which we can instruct use-package -00:11:05.233 --> 00:11:10.239 +00:11:05.320 --> 00:11:10.760 to not download a package using tarball, -00:11:10.240 --> 00:11:12.433 +00:11:10.774 --> 00:11:12.519 but instead to fetch the source code -00:11:12.466 --> 00:11:13.766 +00:11:12.520 --> 00:11:13.799 from a source code repository. -00:11:13.800 --> 00:11:15.566 +00:11:13.800 --> 00:11:15.919 This is useful if you, for example, -00:11:15.600 --> 00:11:18.200 +00:11:15.920 --> 00:11:18.319 have packages which you yourself work on -00:11:18.233 --> 00:11:19.933 +00:11:18.320 --> 00:11:19.959 and know that you always want to have -00:11:19.966 --> 00:11:21.900 +00:11:19.960 --> 00:11:21.919 the development version of the package -00:11:21.900 --> 00:11:26.819 +00:11:21.920 --> 00:11:26.639 where you can directly commit changes you've made -00:11:26.820 --> 00:11:29.733 +00:11:26.640 --> 00:11:29.159 to the repository and push them upstream. -00:11:29.766 --> 00:11:32.100 +00:11:29.160 --> 00:11:32.399 Or, if you know that you want to contribute to a package, -00:11:32.100 --> 00:11:34.966 +00:11:32.400 --> 00:11:35.559 you can use package-vc to download the source code, -00:11:35.000 --> 00:11:37.366 +00:11:35.560 --> 00:11:37.319 have all the version control information, -00:11:37.400 --> 00:11:41.739 +00:11:37.320 --> 00:11:41.759 prepare a patch and send it upstream. -00:11:41.740 --> 00:11:43.800 +00:11:41.760 --> 00:11:44.119 In these examples here, -00:11:43.833 --> 00:11:49.166 +00:11:44.120 --> 00:11:49.119 the first example Lisp instructs package-vc -00:11:49.200 --> 00:11:52.366 +00:11:49.120 --> 00:11:52.959 to download the source code from a URL. -00:11:52.400 --> 00:11:55.400 +00:11:52.960 --> 00:11:55.119 So this is a git URL where it will download -00:11:55.433 --> 00:11:57.400 +00:11:55.120 --> 00:11:57.399 the source code from, and in this case, -00:11:57.433 --> 00:12:00.000 +00:11:57.400 --> 00:12:00.399 choose the newest checkout of the source code, -00:12:00.033 --> 00:12:04.939 +00:12:00.400 --> 00:12:05.680 not the latest release. Down here, we have another example. -00:12:04.940 --> 00:12:08.766 +00:12:05.060 --> 00:12:09.159 I prefer to consider the following example here. -00:12:08.800 --> 00:12:10.733 +00:12:09.160 --> 00:12:10.879 If we just had written this, -00:12:10.766 --> 00:12:13.200 +00:12:10.880 --> 00:12:13.159 then package-vc would use the metadata -00:12:13.233 --> 00:12:15.000 +00:12:13.160 --> 00:12:16.279 which an ELPA server provides -00:12:15.033 --> 00:12:20.166 +00:12:16.280 --> 00:12:19.799 to fetch the URL from the official repository of, -00:12:20.200 --> 00:12:22.833 +00:12:19.800 --> 00:12:22.839 in this case, BBDB, without having to... -00:12:22.866 --> 00:12:27.733 +00:12:22.840 --> 00:12:28.239 It would be more or less the same like this up here, -00:12:27.766 --> 00:12:32.700 +00:12:28.240 --> 00:12:32.639 with the simple difference that package-vc integration -00:12:32.700 --> 00:12:36.300 +00:12:32.640 --> 00:12:36.359 into use-package doesn't check out the latest commit, -00:12:36.300 --> 00:12:37.766 +00:12:36.360 --> 00:12:38.359 but the latest release, -00:12:37.800 --> 00:12:44.979 +00:12:38.360 --> 00:12:44.159 just to keep configurations more deterministic by default. -00:12:44.980 --> 00:12:47.566 +00:12:44.160 --> 00:12:47.879 Of course, if you prefer to use latest commit, -00:12:47.600 --> 00:12:52.179 +00:12:47.880 --> 00:12:52.439 you can use a package-vc install command -00:12:52.180 --> 00:12:54.933 +00:12:52.440 --> 00:12:54.879 or just update the package manually yourself, -00:12:54.966 --> 00:13:01.779 +00:12:54.880 --> 00:13:01.739 which you can use using package-vc-upgrade. -00:13:01.780 --> 00:13:04.366 +00:13:01.740 --> 00:13:04.319 Next, I'd like to focus on a few features -00:13:04.400 --> 00:13:07.000 +00:13:04.320 --> 00:13:07.740 which one might not necessarily realize directly, -00:13:07.033 --> 00:13:11.559 +00:13:07.741 --> 00:13:11.399 but will hopefully improve your experience with Emacs. NOTE JSON -00:13:11.560 --> 00:13:15.133 +00:13:11.400 --> 00:13:15.119 First up in this list is a new JSON parser. -00:13:15.166 --> 00:13:21.959 +00:13:15.120 --> 00:13:21.399 Let's maybe show the source code for that one: -00:13:21.960 --> 00:13:39.533 +00:13:21.400 --> 00:13:39.319 not json.el, json.c. The history of JSON parsing in Emacs -00:13:39.566 --> 00:13:43.366 +00:13:39.320 --> 00:13:43.279 started with Emacs 23 with the addition of json.el. -00:13:43.400 --> 00:13:46.766 +00:13:43.280 --> 00:13:46.919 This was the file which we had just opened a moment ago. -00:13:46.800 --> 00:13:50.366 +00:13:46.920 --> 00:13:50.959 This is a JSON parser in Emacs Lisp. -00:13:50.400 --> 00:13:53.233 +00:13:50.960 --> 00:13:53.199 It's fine, it does the job, but it can get slow -00:13:53.266 --> 00:13:55.000 +00:13:53.200 --> 00:13:55.479 if we have a situation like where -00:13:55.033 --> 00:14:00.319 +00:13:55.480 --> 00:14:00.479 Eglot uses a LSP server to communicate with -00:14:00.320 --> 00:14:02.999 +00:14:00.480 --> 00:14:02.959 and the LSP server can get a bit chatty, -00:14:03.000 --> 00:14:05.133 +00:14:02.960 --> 00:14:05.479 sending a lot of JSON data, -00:14:05.166 --> 00:14:07.966 +00:14:05.480 --> 00:14:08.199 which all has to be parsed and garbage collected, -00:14:08.000 --> 00:14:09.933 +00:14:08.200 --> 00:14:10.199 which can slow down Emacs a bit. -00:14:09.966 --> 00:14:13.733 +00:14:10.200 --> 00:14:14.119 The situation was improved upon in Emacs 29 -00:14:13.766 --> 00:14:18.000 +00:14:14.120 --> 00:14:17.959 when JSON parsing was added to the core. -00:14:18.033 --> 00:14:21.000 +00:14:17.960 --> 00:14:21.039 This was the json.c file, which we see on this side, -00:14:21.033 --> 00:14:22.733 +00:14:21.040 --> 00:14:23.279 the old version of the json.c file, -00:14:22.766 --> 00:14:26.700 +00:14:23.280 --> 00:14:27.119 which employed the Jansson library (it's the C library) -00:14:26.700 --> 00:14:31.899 +00:14:27.120 --> 00:14:33.159 for parsing and accelerating JSON parsing in Emacs. -00:14:31.900 --> 00:14:33.966 +00:14:33.160 --> 00:14:33.999 This was good enough, -00:14:34.000 --> 00:14:36.200 +00:14:34.000 --> 00:14:36.159 or it certainly improved the situation -00:14:36.233 --> 00:14:38.300 +00:14:36.160 --> 00:14:38.559 for a lot of LSP clients. -00:14:38.300 --> 00:14:44.766 +00:14:38.560 --> 00:14:45.479 But in Emacs 30, the situation has been improved once more -00:14:44.800 --> 00:14:49.800 +00:14:45.480 --> 00:14:50.359 with the addition of a JSON parser directly in Emacs. -00:14:49.833 --> 00:14:53.566 +00:14:50.360 --> 00:14:52.999 So instead of using an external library, -00:14:53.600 --> 00:14:57.400 +00:14:53.000 --> 00:14:57.719 there's a custom JSON parser written in C in the Emacs core, -00:14:57.433 --> 00:15:01.539 +00:14:57.720 --> 00:15:01.559 which directly generates Elisp objects. -00:15:01.540 --> 00:15:05.033 +00:15:01.560 --> 00:15:04.999 The advantage to this approach -00:15:05.066 --> 00:15:06.433 +00:15:05.000 --> 00:15:06.359 compared to the Jansson approach -00:15:06.466 --> 00:15:07.933 +00:15:06.360 --> 00:15:07.919 is that there's no intermediate format -00:15:07.966 --> 00:15:09.200 +00:15:07.920 --> 00:15:09.199 which has to be allocated -00:15:09.233 --> 00:15:11.500 +00:15:09.200 --> 00:15:11.559 and memory managed and freed again, -00:15:11.500 --> 00:15:19.539 +00:15:11.560 --> 00:15:19.479 which of course incurs an additional performance overhead. -00:15:19.540 --> 00:15:22.433 +00:15:19.480 --> 00:15:22.659 Next to this, there's also a custom serializer -00:15:22.466 --> 00:15:29.239 +00:15:22.660 --> 00:15:27.119 for JSON contents translating a JSON object into a string. -00:15:29.240 --> 00:15:30.640 +00:15:27.120 --> 00:15:30.279 ... The consequence of this is that -00:15:30.641 --> 00:15:35.519 +00:15:30.280 --> 00:15:35.600 there is absolutely no dependency on Jansson anymore. -00:15:35.520 --> 00:15:38.533 +00:15:35.640 --> 00:15:38.559 This in turn means that now all Emacs users -00:15:38.566 --> 00:15:39.800 +00:15:38.560 --> 00:15:39.799 from Emacs 30 onwards -00:15:39.833 --> 00:15:42.733 +00:15:39.800 --> 00:15:43.119 can take advantage of this new JSON parser -00:15:42.766 --> 00:15:44.933 +00:15:43.120 --> 00:15:44.879 and don't have to worry about whether -00:15:44.966 --> 00:15:47.633 +00:15:44.880 --> 00:15:47.799 or not they have Jansson, this JSON parsing library, -00:15:47.666 --> 00:15:50.433 +00:15:47.800 --> 00:15:50.999 installed on their system or not when they want -00:15:50.466 --> 00:15:56.679 +00:15:51.000 --> 00:15:56.839 to take advantage of this accelerated JSON parsing. NOTE Native compilation -00:15:56.680 --> 00:16:00.366 +00:15:56.840 --> 00:16:00.639 Next up, another behind-the-scenes feature -00:16:00.400 --> 00:16:06.406 +00:16:00.640 --> 00:16:04.559 is that if you build Emacs on your own from source, -00:16:06.407 --> 00:16:07.766 +00:16:04.560 --> 00:16:07.879 you might know that if you wanted -00:16:07.800 --> 00:16:09.533 +00:16:07.880 --> 00:16:09.559 to use native compilation, -00:16:09.566 --> 00:16:12.379 +00:16:09.560 --> 00:16:12.319 so the translation of Elisp bytecodes -00:16:12.380 --> 00:16:15.533 +00:16:12.320 --> 00:16:15.559 to whatever the native assembly -00:16:15.566 --> 00:16:19.133 +00:16:15.560 --> 00:16:19.319 or native instruction set is on your system, -00:16:19.166 --> 00:16:24.339 +00:16:19.320 --> 00:16:24.359 you have to specify with native compilation. -00:16:24.340 --> 00:16:25.933 +00:16:24.360 --> 00:16:25.879 when invoking the configure script, -00:16:25.966 --> 00:16:28.366 +00:16:25.880 --> 00:16:28.879 otherwise it would not have been enabled at all. -00:16:28.400 --> 00:16:32.479 +00:16:28.880 --> 00:16:34.119 With Emacs 30, this step is not necessary anymore. -00:16:32.480 --> 00:16:36.233 +00:16:34.120 --> 00:16:36.719 The configure script will automatically check -00:16:36.266 --> 00:16:41.700 +00:16:36.720 --> 00:16:41.759 if you have the libgccjit library installed on your system, -00:16:41.700 --> 00:16:42.766 +00:16:41.760 --> 00:16:42.879 and if that is so, -00:16:42.800 --> 00:16:45.566 +00:16:42.880 --> 00:16:45.999 then native compilation will be enabled by default. -00:16:45.600 --> 00:16:49.400 +00:16:46.000 --> 00:16:49.559 In other words, if you have an issue with native compilation -00:16:49.433 --> 00:16:52.500 +00:16:49.560 --> 00:16:52.799 or prefer not to use it for whatever reason, -00:16:52.500 --> 00:16:55.533 +00:16:52.800 --> 00:16:55.559 you now have to type --without-native-compilation -00:16:55.566 --> 00:16:58.433 +00:16:55.560 --> 00:16:58.199 when compiling Emacs to prevent this from happening. -00:16:58.466 --> 00:17:02.433 +00:16:58.200 --> 00:17:02.279 But native compilation was added in Emacs 28 -00:17:02.466 --> 00:17:04.333 +00:17:02.280 --> 00:17:04.399 and has proven to be a very stable -00:17:04.366 --> 00:17:06.233 +00:17:04.400 --> 00:17:06.199 and useful feature for most people, -00:17:06.266 --> 00:17:09.400 +00:17:06.200 --> 00:17:10.199 so there's probably no reason to do this -00:17:09.433 --> 00:17:11.133 +00:17:10.200 --> 00:17:10.939 and you can just invoke the configure script -00:17:11.166 --> 00:17:16.300 +00:17:10.940 --> 00:17:16.239 with one argument less. Right, and I'd like to finish up -00:17:16.300 --> 00:17:19.500 +00:17:16.240 --> 00:17:19.399 with a few smaller features, a few smaller highlights. -00:17:19.500 --> 00:17:29.639 +00:17:19.400 --> 00:17:30.719 Maybe we can go back to the listing here. Here we have it. NOTE Tree-sitter -00:17:29.640 --> 00:17:32.833 +00:17:30.720 --> 00:17:32.839 There are a few new major modes -00:17:32.866 --> 00:17:34.333 +00:17:32.840 --> 00:17:34.239 based on the tree-sitter library. -00:17:34.366 --> 00:17:37.939 +00:17:34.240 --> 00:17:37.739 tree-sitter is this parser library -00:17:37.940 --> 00:17:39.933 +00:17:37.740 --> 00:17:42.879 which has been integrated into Emacs 29. -00:17:39.966 --> 00:17:44.100 +00:17:42.880 --> 00:17:44.079 It allows the integration -00:17:44.100 --> 00:17:48.400 +00:17:44.080 --> 00:17:48.359 of external, specialized, and quick parsers into Emacs, -00:17:48.433 --> 00:17:52.133 +00:17:48.360 --> 00:17:52.119 which improve stuff like syntax highlighting, indentation, -00:17:52.166 --> 00:17:55.233 +00:17:52.120 --> 00:17:55.279 structural navigation, imenu support, -00:17:55.266 --> 00:18:01.033 +00:17:55.280 --> 00:18:00.839 by simply having a better understanding of, for example, -00:18:01.066 --> 00:18:03.900 +00:18:00.840 --> 00:18:03.919 a HTML file, or a Lua file, a PHP file, -00:18:03.900 --> 00:18:06.233 +00:18:03.920 --> 00:18:06.239 than what people usually implement -00:18:06.266 --> 00:18:10.366 +00:18:06.240 --> 00:18:10.319 using regular expressions in traditional major modes. -00:18:10.400 --> 00:18:16.779 +00:18:10.320 --> 00:18:16.819 So, a few new major modes which you can try out here. NOTE Completion preview mode -00:18:16.780 --> 00:18:20.033 +00:18:16.820 --> 00:18:19.959 Another interesting feature is the completion-preview-mode. -00:18:20.066 --> 00:18:22.966 +00:18:19.960 --> 00:18:23.319 We can maybe try it out here in the scratch buffer. -00:18:23.000 --> 00:18:28.300 +00:18:23.320 --> 00:18:28.199 If I enable completion-preview-mode... -00:18:28.300 --> 00:18:32.033 +00:18:28.200 --> 00:18:32.719 This is a non-global minor mode, -00:18:32.066 --> 00:18:38.600 +00:18:32.720 --> 00:18:38.479 which will display completion options inline using overlays. -00:18:38.633 --> 00:18:43.133 +00:18:38.480 --> 00:18:43.199 For example, if I start typing a longer symbol like define, -00:18:43.166 --> 00:18:48.200 +00:18:43.200 --> 00:18:48.119 now we have a derived mode. It suggests me to... -00:18:48.233 --> 00:18:51.133 +00:18:48.120 --> 00:18:51.039 I can just press TAB and then it completes the option here, -00:18:51.166 --> 00:18:51.933 +00:18:51.040 --> 00:18:51.839 but it didn't actually... -00:18:51.966 --> 00:18:55.333 +00:18:51.840 --> 00:18:55.279 It's not actually modifying the buffer, it's not pressing, -00:18:55.366 --> 00:18:57.100 +00:18:55.280 --> 00:18:57.039 these are just overlays, -00:18:57.100 --> 00:18:59.533 +00:18:57.040 --> 00:18:59.519 so if I move around, it gets deleted. -00:18:59.566 --> 00:19:02.619 +00:18:59.520 --> 00:19:02.539 It wouldn't get saved if I were to save the buffer. -00:19:02.620 --> 00:19:04.966 +00:19:02.540 --> 00:19:04.999 The same also should work in a shell buffer. -00:19:05.000 --> 00:19:08.366 +00:19:05.000 --> 00:19:09.239 If I enable completion preview mode here and start... -00:19:08.400 --> 00:19:12.800 +00:19:09.240 --> 00:19:12.759 In this case, I'm using the bash completion package, -00:19:12.833 --> 00:19:15.000 +00:19:12.760 --> 00:19:15.199 which provides additional completion information. -00:19:15.033 --> 00:19:17.933 +00:19:15.200 --> 00:19:17.839 This is not only limited to programming systems, -00:19:17.966 --> 00:19:22.900 +00:19:17.840 --> 00:19:22.919 but anywhere where you have completion at point in Emacs. -00:19:22.900 --> 00:19:26.159 +00:19:22.920 --> 00:19:26.059 I can start typing here, ignore, and put ignore-backups, -00:19:26.160 --> 00:19:30.000 +00:19:26.060 --> 00:19:29.919 and it hints to the options which I have -00:19:30.033 --> 00:19:34.200 +00:19:29.920 --> 00:19:34.219 and allows me to complete them quickly. NOTE package-isolate -00:19:34.233 --> 00:19:37.966 +00:19:34.220 --> 00:19:37.879 Another small feature is the package-isolate command. -00:19:38.000 --> 00:19:40.000 +00:19:37.880 --> 00:19:39.959 What this does is it will start -00:19:40.033 --> 00:19:42.800 +00:19:39.960 --> 00:19:42.759 or it will prompt me for packages -00:19:42.833 --> 00:19:44.333 +00:19:42.760 --> 00:19:44.119 I have installed in my system -00:19:44.366 --> 00:19:46.500 +00:19:44.120 --> 00:19:46.439 and will start an isolated -00:19:46.500 --> 00:19:51.133 +00:19:46.440 --> 00:19:51.079 or like "emacs -Q"-ish instance of emacs -00:19:51.166 --> 00:19:53.333 +00:19:51.080 --> 00:19:53.639 with only these packages installed. -00:19:53.366 --> 00:20:00.439 +00:19:53.640 --> 00:20:00.279 So for example, if I said I want slime and I want diff-hl, -00:20:00.440 --> 00:20:02.700 +00:20:00.280 --> 00:20:02.279 then this is a new Emacs window. -00:20:02.700 --> 00:20:04.533 +00:20:02.280 --> 00:20:04.439 It's unrelated to the one around. -00:20:04.566 --> 00:20:06.500 +00:20:04.440 --> 00:20:06.839 It uses the same executable, of course, -00:20:06.500 --> 00:20:09.939 +00:20:06.840 --> 00:20:09.939 but will not load your configuration file -00:20:09.940 --> 00:20:13.679 +00:20:09.940 --> 00:20:13.619 or any other further customizations on your system. -00:20:13.680 --> 00:20:15.533 +00:20:13.620 --> 00:20:15.159 All it does, it will ensure -00:20:15.566 --> 00:20:17.933 +00:20:15.160 --> 00:20:17.919 that these packages, which are listed here, -00:20:17.966 --> 00:20:24.599 +00:20:17.920 --> 00:20:24.499 so in our case SLIME and dependencies of SLIME and diff-hl, -00:20:24.600 --> 00:20:25.300 +00:20:24.500 --> 00:20:25.239 in the system -00:20:25.300 --> 00:20:29.100 +00:20:25.240 --> 00:20:29.039 so that I could, for example, as you can see here, -00:20:29.100 --> 00:20:32.139 +00:20:29.040 --> 00:20:31.959 diff-hl-mode works. -00:20:32.140 --> 00:20:34.766 +00:20:31.960 --> 00:20:35.479 Okay, this is not a version-controlled file. -00:20:34.800 --> 00:20:41.200 +00:20:35.480 --> 00:20:41.119 Maybe if we take a look at, have I enabled diff-hl-mode? -00:20:41.233 --> 00:20:44.600 +00:20:41.120 --> 00:20:44.559 It's enabled in this case. What diff-hl-mode does -00:20:44.633 --> 00:20:48.300 +00:20:44.560 --> 00:20:48.479 is it displays these version control changes -00:20:48.300 --> 00:20:49.566 +00:20:48.480 --> 00:20:49.999 in the fringe of a buffer. -00:20:49.600 --> 00:20:54.133 +00:20:50.000 --> 00:20:54.079 And even though this is a uncustomized version of Emacs, -00:20:54.166 --> 00:20:56.333 +00:20:54.080 --> 00:20:56.319 or an uncustomized instance of Emacs, -00:20:56.366 --> 00:20:59.000 +00:20:56.320 --> 00:20:58.959 it was easy for me to load this one package, -00:20:59.033 --> 00:21:02.033 +00:20:58.960 --> 00:21:01.959 or these two packages and all the dependencies necessary. -00:21:02.066 --> 00:21:05.300 +00:21:01.960 --> 00:21:05.319 As you can imagine, the main purpose for this -00:21:05.300 --> 00:21:07.733 +00:21:05.320 --> 00:21:07.719 is to make debugging issues easier. -00:21:07.766 --> 00:21:10.566 +00:21:07.720 --> 00:21:10.519 If you want to report about an issue -00:21:10.600 --> 00:21:14.900 +00:21:10.520 --> 00:21:14.519 you have with a package. And if I close this, it's closed -00:21:14.900 --> 00:21:16.919 +00:21:14.520 --> 00:21:16.779 and everything's thrown away. NOTE Reindenting -00:21:16.920 --> 00:21:19.000 +00:21:16.780 --> 00:21:18.959 Last up, a nice feature I think -00:21:19.033 --> 00:21:20.933 +00:21:18.960 --> 00:21:21.199 a lot of people will appreciate is, -00:21:20.966 --> 00:21:24.300 +00:21:21.200 --> 00:21:24.239 if you are familiar with... Let's open a text buffer. -00:21:24.300 --> 00:21:30.279 +00:21:24.240 --> 00:21:30.079 The M-q key is traditionally bound to fill-paragraph. -00:21:30.280 --> 00:21:32.200 +00:21:30.080 --> 00:21:32.119 What this means is that... -00:21:32.233 --> 00:21:35.000 +00:21:32.120 --> 00:21:34.999 Let's, for example, copy this text from here -00:21:35.033 --> 00:21:40.366 +00:21:35.000 --> 00:21:40.359 and squash it all into one line. If I press M-q here, -00:21:40.400 --> 00:21:42.719 +00:21:40.360 --> 00:21:42.399 then the lines will be broken -00:21:42.720 --> 00:21:49.879 +00:21:42.400 --> 00:21:49.479 according to the fill column indicator up here. -00:21:49.880 --> 00:21:52.600 +00:21:49.480 --> 00:21:52.399 This is the traditional usage of M-q, -00:21:52.633 --> 00:21:54.200 +00:21:52.400 --> 00:21:54.119 and it still works in text-mode buffers, -00:21:54.233 --> 00:21:55.859 +00:21:54.120 --> 00:21:56.639 but in prog-mode buffers-- -00:21:55.860 --> 00:22:00.100 +00:21:56.640 --> 00:22:00.079 so any major mode inheriting prog-mode-- -00:22:00.100 --> 00:22:02.233 +00:22:00.080 --> 00:22:02.199 M-q will now by default be bound -00:22:02.266 --> 00:22:09.779 +00:22:02.200 --> 00:22:09.719 to prog-fill-reindent-defun. To summarize the point, -00:22:09.780 --> 00:22:13.433 +00:22:09.720 --> 00:22:13.479 if you are editing a string or a comment, -00:22:13.466 --> 00:22:16.039 +00:22:13.480 --> 00:22:15.919 then the comment will be filled. -00:22:16.040 --> 00:22:19.100 +00:22:15.920 --> 00:22:19.159 But if you are outside of a comment or outside of a string, -00:22:19.100 --> 00:22:23.166 +00:22:19.160 --> 00:22:22.919 then the defun or the top-level construct -00:22:23.200 --> 00:22:26.159 +00:22:22.920 --> 00:22:26.119 in the programming language will be re-indented. -00:22:26.160 --> 00:22:34.099 +00:22:26.120 --> 00:22:33.859 Let's try that out with maybe some file I have open here. -00:22:34.100 --> 00:22:38.800 +00:22:33.860 --> 00:22:38.819 If I'm in this... Let's choose some function, -00:22:38.833 --> 00:22:40.733 +00:22:38.820 --> 00:22:41.279 let's take this for example. -00:22:40.766 --> 00:22:43.959 +00:22:41.280 --> 00:22:43.879 If we followed all of this again, -00:22:43.960 --> 00:22:47.400 +00:22:43.880 --> 00:22:47.619 and I press M-q in on this paragraph, -00:22:47.433 --> 00:22:49.433 +00:22:47.620 --> 00:22:50.039 then the paragraph gets re-indented. -00:22:49.466 --> 00:22:55.800 +00:22:50.040 --> 00:22:54.859 But if I'm down here and I choose to break the indentation -00:22:55.833 --> 00:22:58.166 +00:22:54.860 --> 00:22:56.180 and then press M-q, -00:22:58.200 --> 00:23:02.333 +00:22:56.181 --> 00:23:02.399 then as you see, it practically selected the defun -00:23:02.366 --> 00:23:03.566 +00:23:02.400 --> 00:23:03.559 and re-indented everything -00:23:03.600 --> 00:23:06.959 -without having me to move the point around in the buffer. +00:23:03.560 --> 00:23:05.959 +without having need to move the point around in the buffer. -00:23:06.960 --> 00:23:08.633 +00:23:06.800 --> 00:23:08.679 So I think that's a really nice feature, -00:23:08.666 --> 00:23:11.100 +00:23:08.680 --> 00:23:11.039 which a lot of people can appreciate. -00:23:11.100 --> 00:23:17.939 +00:23:11.040 --> 00:23:17.879 It's one of those niceties which comes from time to time. NOTE Wrapping up -00:23:17.940 --> 00:23:20.633 +00:23:17.880 --> 00:23:20.679 Right, so that was my overview -00:23:20.666 --> 00:23:22.600 +00:23:20.680 --> 00:23:22.559 of what's going to be new in Emacs 30. -00:23:22.633 --> 00:23:24.400 +00:23:22.560 --> 00:23:24.359 I hope that most people could take away -00:23:24.433 --> 00:23:25.579 +00:23:24.360 --> 00:23:25.659 something from this presentation -00:23:25.580 --> 00:23:28.900 +00:23:25.660 --> 00:23:29.419 and have something to look forward -00:23:28.900 --> 00:23:31.133 +00:23:29.420 --> 00:23:31.599 to try out after upgrading. -00:23:31.166 --> 00:23:33.833 +00:23:31.600 --> 00:23:33.839 As mentioned initially, as of recording, -00:23:33.866 --> 00:23:36.566 +00:23:33.840 --> 00:23:36.939 this release has not been completed yet. -00:23:36.600 --> 00:23:38.833 +00:23:36.940 --> 00:23:38.879 If this is still not the case -00:23:38.866 --> 00:23:40.233 +00:23:38.880 --> 00:23:40.199 when you're seeing this video, -00:23:40.266 --> 00:23:43.833 +00:23:40.200 --> 00:23:43.799 please consider downloading and building Emacs 30 yourself. -00:23:43.866 --> 00:23:48.200 +00:23:43.800 --> 00:23:48.319 If you have any issues, which is always the case, -00:23:48.233 --> 00:23:56.439 +00:23:48.320 --> 00:23:56.339 please report them to using report-emacs-bug. -00:23:56.440 --> 00:23:57.907 +00:23:56.340 --> 00:23:57.740 That will pop up a mail buffer, -00:23:57.908 --> 00:23:59.600 +00:23:57.741 --> 00:23:59.519 and then you can describe your issue and send them out. -00:23:59.633 --> 00:24:01.800 +00:23:59.520 --> 00:24:01.839 All bug reports are valuable, -00:24:01.833 --> 00:24:04.433 +00:24:01.840 --> 00:24:03.999 even if they are false positives or duplicates-- -00:24:04.466 --> 00:24:05.233 +00:24:04.000 --> 00:24:05.239 it doesn't matter-- -00:24:05.266 --> 00:24:08.533 +00:24:05.240 --> 00:24:08.919 because when you take the time to submit a bug report, -00:24:08.566 --> 00:24:12.233 +00:24:08.920 --> 00:24:12.359 which describes something that's specific to your setup, -00:24:12.266 --> 00:24:16.700 +00:24:12.360 --> 00:24:16.839 which the developers might not have noticed or known about, -00:24:16.700 --> 00:24:19.133 +00:24:16.840 --> 00:24:19.079 then you are certainly helping out a lot of other people -00:24:19.166 --> 00:24:21.766 +00:24:19.080 --> 00:24:21.679 which might run into the same issue in the future. -00:24:21.800 --> 00:24:23.200 +00:24:21.680 --> 00:24:23.359 Especially with upgrades, -00:24:23.233 --> 00:24:26.566 +00:24:23.360 --> 00:24:26.559 it would be nice to figure out small problems -00:24:26.600 --> 00:24:30.800 +00:24:26.560 --> 00:24:30.879 which make upgrading difficult for some people. -00:24:30.833 --> 00:24:34.700 +00:24:30.880 --> 00:24:34.559 The ideal is, of course, to have no issues -00:24:34.700 --> 00:24:37.199 +00:24:34.560 --> 00:24:37.199 when upgrading from one version to another. -00:24:37.200 --> 00:24:39.566 +00:24:37.200 --> 00:24:41.939 Having said that, I thank you for your attention, -00:24:39.600 --> 00:24:43.766 +00:24:41.940 --> 00:24:43.120 and I'm saying goodbye. 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-org-update--the-future-of-org--ihor-radchenko--main.vtt b/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.vtt index 6b092bd1..9a13366b 100644 --- a/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.vtt +++ b/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.vtt @@ -1810,7 +1810,7 @@ participate in the mailing list, it's not ideal, but I can still work with this. I am on IRC, I am on Matrix, 00:35:16.006 --> 00:35:19.799 -you can ping me, it's yantar2. +you can ping me, it's yantar92. 00:35:19.800 --> 00:35:22.347 We also have monthly meetup, 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, |