WEBVTT 00:00:00.000 --> 00:00:01.479 The first question, 00:00:01.480 --> 00:00:03.599 and I'm reading from the etherpad here, 00:00:03.600 --> 00:00:05.519 is there a scope for integrating 00:00:05.520 --> 00:00:07.839 the C library to Emacs itself 00:00:07.840 --> 00:00:13.159 with MuPDF becoming an optional dependency? 00:00:13.160 --> 00:00:18.719 Right, so integrating the C library into Emacs itself 00:00:18.720 --> 00:00:24.359 is like having MuPDF inside Emacs source tree. 00:00:24.360 --> 00:00:27.999 I don't think Emacs devs would be inclined to do that, 00:00:28.000 --> 00:00:30.079 and I don't think we really need it. 00:00:30.080 --> 00:00:33.039 Um, I think as it is, uh, Emacs 00:00:33.040 --> 00:00:36.439 with doc view needs new tool, which is something you need 00:00:36.440 --> 00:00:38.919 to install from new PDF anyways. 00:00:38.920 --> 00:00:42.599 So, um, I think it is almost expected 00:00:42.600 --> 00:00:46.279 that you install new PDF from system package manager. 00:00:46.280 --> 00:00:49.119 Um, and I think that as it is, is better 00:00:49.120 --> 00:00:50.999 because we don't really need to have 00:00:51.000 --> 00:00:53.439 a whole PDF engine inside Emacs. 00:00:53.440 --> 00:00:59.879 Um, Next question also from the pad, 00:00:59.880 --> 00:01:01.759 the dynamic module some great, 00:01:01.760 --> 00:01:06.639 and it's amazing that they've been there since 2017. 00:01:06.640 --> 00:01:09.839 Why do you think they've been slowly 00:01:09.840 --> 00:01:11.559 so slow to get adopted? 00:01:11.560 --> 00:01:14.279 Is there a prior art with them? Right? 00:01:14.280 --> 00:01:16.359 That's a good question. 00:01:16.360 --> 00:01:22.119 Actually, I think 1 of the reasons is that. 00:01:22.120 --> 00:01:24.919 Most of the time, I think people love Emacs 00:01:24.920 --> 00:01:27.519 because they can do so much with Elisp. 00:01:27.520 --> 00:01:28.919 I think certainly there is a bias 00:01:28.920 --> 00:01:31.319 towards trying to do things with Elisp. 00:01:31.320 --> 00:01:35.039 I think there's only a sort of specific class of problems 00:01:35.040 --> 00:01:36.879 that you can solve with dynamic modules, 00:01:36.880 --> 00:01:40.879 such as this, where you want to use a native library 00:01:40.880 --> 00:01:44.239 to do something in a faster, better way. 00:01:44.240 --> 00:01:48.959 I use that quite a lot. 00:01:48.960 --> 00:01:53.319 There's of course libvterm, which uses a dynamic module 00:01:53.320 --> 00:01:55.119 and it does it really well. 00:01:55.120 --> 00:02:00.439 And I think there's another one, a plotting library 00:02:00.440 --> 00:02:05.879 or package in Emacs that was using something from Python. 00:02:05.880 --> 00:02:07.879 So, dynamic modules are good, 00:02:07.880 --> 00:02:10.039 but I think they don't really come 00:02:10.040 --> 00:02:13.974 to the surface level packages, your day-to-day packages, 00:02:13.975 --> 00:02:17.359 because most of the day-to-day packages that we use in Emacs 00:02:17.360 --> 00:02:20.879 can be done with Elisp. So, unless you really need 00:02:20.880 --> 00:02:23.199 something system-level efficient, 00:02:23.200 --> 00:02:29.519 Most of the time, you don't want to write C or C++ or something. 00:02:29.520 --> 00:02:34.919 But there is actually a really nice Rust crate for native modules, 00:02:34.920 --> 00:02:37.239 and there's a really nice Haskell package. 00:02:37.240 --> 00:02:39.879 So there's actually really good support 00:02:39.880 --> 00:02:41.279 for multiple languages. 00:02:41.280 --> 00:02:45.799 So it's there, it's just not used as much. Yeah. 00:02:45.800 --> 00:02:47.039 So what you're saying is 00:02:47.040 --> 00:02:51.279 if Elisp weren't so simple to learn and easy to use 00:02:51.280 --> 00:02:52.879 and so fully featured, 00:02:52.880 --> 00:02:54.959 we'd get a lot more mileage 00:02:54.960 --> 00:02:57.799 out of this super cool dynamic module feature. 00:02:57.800 --> 00:03:02.159 Yeah. Cool I'll take I'll bring in the next question. 00:03:02.160 --> 00:03:07.399 How how? How difficult is our PDF tools to install? 00:03:07.400 --> 00:03:10.439 The questioner is installing it 00:03:10.440 --> 00:03:12.519 using the built-in package manager 00:03:12.520 --> 00:03:16.679 looking at the Emacs reader installation instructions 00:03:16.680 --> 00:03:18.479 It doesn't necessarily cover 00:03:18.480 --> 00:03:20.399 how how to install that easily 00:03:20.400 --> 00:03:25.679 person is not using use package or straight and Okay. 00:03:25.680 --> 00:03:27.959 Oh, and they say that you didn't 00:03:27.960 --> 00:03:32.439 catch much of this in the presentation. 00:03:32.440 --> 00:03:35.079 Okay, so you want me to skip that or should I answer? 00:03:35.080 --> 00:03:38.159 It's your choice. If you would like to say more. 00:03:38.160 --> 00:03:40.519 Yeah, I think just as a thing, 00:03:40.520 --> 00:03:43.319 the reason I said PDF tools is difficult 00:03:43.320 --> 00:03:45.839 is PDF tools has a huge list of dependencies. 00:03:45.840 --> 00:03:47.639 The only thing Emacs Vita depends 00:03:47.640 --> 00:03:50.599 on is new PDF, nothing else. There's a single dependency. 00:03:50.600 --> 00:03:54.479 PDF tools depends on a lot of things 00:03:54.480 --> 00:03:57.759 and they have their own server, 00:03:57.760 --> 00:04:00.039 which is packaged as a system package, 00:04:00.040 --> 00:04:02.359 which you don't really find everywhere. 00:04:02.360 --> 00:04:05.039 And there's like systems, the new Linux systems 00:04:05.040 --> 00:04:07.359 where the package is very difficult to build 00:04:07.360 --> 00:04:10.079 because of so many dependencies. 00:04:10.080 --> 00:04:13.159 So my goal was to sort of reduce 00:04:13.160 --> 00:04:14.839 the number of dependencies. 00:04:14.840 --> 00:04:19.559 And then right now it's very, it's sort of a key 00:04:19.560 --> 00:04:21.119 to install Emacs Reader. 00:04:21.120 --> 00:04:23.319 Once we go to GNU Elpa, it's just 00:04:23.320 --> 00:04:25.999 going to be Emacs package install, just that. 00:04:26.000 --> 00:04:27.919 Right now you have to do package VC 00:04:27.920 --> 00:04:32.359 a bit. Boy, we get spoiled as 00:04:32.360 --> 00:04:35.359 Emacs users. Everything just gets so easy 00:04:35.360 --> 00:04:37.959 for us. It's like an IDE for our 00:04:37.960 --> 00:04:44.839 whole machine. What tools did you use to measure the 00:04:44.840 --> 00:04:48.879 memory usage between the three packages? 00:04:48.880 --> 00:04:50.119 Yeah, that's a good question. 00:04:50.120 --> 00:04:54.799 So during my development, I used mostly for debugging 00:04:54.800 --> 00:05:00.119 purposes Valgrind. So Valgrind is a a set of suite 00:05:00.120 --> 00:05:01.559 of debugging tools. 00:05:01.560 --> 00:05:03.799 And one of the tools that it has is Massive. 00:05:03.800 --> 00:05:08.919 It's a heap analyzer, heap profiler. 00:05:08.920 --> 00:05:10.839 So Valgrind plus Massive, 00:05:10.840 --> 00:05:14.119 and then there's a KDE package 00:05:14.120 --> 00:05:15.759 called Massive Visualizer. 00:05:15.760 --> 00:05:19.839 So I first get the Massive output using Valgrind, 00:05:19.840 --> 00:05:23.159 and then put that output into Massive Visualizer. 00:05:23.160 --> 00:05:24.519 That gives me the grasp. 00:05:24.520 --> 00:05:28.599 Are there Emacs integrations for those components at all? 00:05:28.600 --> 00:05:30.279 Does Valgrind have them? 00:05:30.280 --> 00:05:32.399 I don't think so. I don't think so. 00:05:32.400 --> 00:05:37.319 There's, yeah, there's I think a few packages 00:05:37.320 --> 00:05:38.879 which do something with Massive, 00:05:38.880 --> 00:05:42.159 but I don't think like they're maintained. 00:05:42.160 --> 00:05:47.759 Yeah. Gotcha. Cool. Awesome opportunity 00:05:47.760 --> 00:05:49.399 there for someone spunky. 00:05:49.400 --> 00:05:55.399 How is conversion between Elisp and foreign language types? 00:05:55.400 --> 00:05:59.039 For example, when interfacing with the C++ library 00:05:59.040 --> 00:06:03.439 that makes heavy use of the C++ object system and templates. 00:06:03.440 --> 00:06:05.879 Yeah, that's a good question. 00:06:05.880 --> 00:06:10.519 So the go-to answer is the blog post that I wrote, 00:06:10.520 --> 00:06:12.199 which is an extensive explanation 00:06:12.200 --> 00:06:14.679 on how the internals of dynamic modules work. 00:06:14.680 --> 00:06:21.119 The short answer is that basically what happens 00:06:21.120 --> 00:06:24.639 is anything that is compatible with C-ABI 00:06:24.640 --> 00:06:27.759 When you compile that language code, 00:06:27.760 --> 00:06:33.559 so when I compile C++ code, I would have a particular API. 00:06:33.560 --> 00:06:35.799 So we have a dynamic module API, 00:06:35.800 --> 00:06:39.119 which is the emacs-module.h, the file that I showed. 00:06:39.120 --> 00:06:45.799 You have to put that into your C++ package program 00:06:45.800 --> 00:06:48.679 and then link it to... 00:06:48.680 --> 00:06:51.119 So emacs-module.h is basically going to... 00:06:51.120 --> 00:06:56.799 like use things in your Emacs installation 00:06:56.800 --> 00:07:04.359 to interact with this C++ language. So it's basically FFI. 00:07:04.360 --> 00:07:10.959 And what this gives you is that you can have things in C++. 00:07:10.960 --> 00:07:13.119 So let's say you want to do multi-threading 00:07:13.120 --> 00:07:15.279 the way I did system level multi-threading. 00:07:15.280 --> 00:07:20.519 You can have C++ be responsible for the multi-threading. 00:07:20.520 --> 00:07:22.999 but you want the output 00:07:23.000 --> 00:07:24.879 of the multithreading to go into Emacs. 00:07:24.880 --> 00:07:29.039 So then you write like a piece of C++ function, 00:07:29.040 --> 00:07:31.879 which is going to be a dynamic module function. 00:07:31.880 --> 00:07:32.919 A dynamic module function 00:07:32.920 --> 00:07:34.959 is written in the language that you target, 00:07:34.960 --> 00:07:37.359 that is C++ or C or Rust. 00:07:37.360 --> 00:07:40.759 And then that is going to be compiled 00:07:40.760 --> 00:07:43.279 into a share library like SO. 00:07:43.280 --> 00:07:46.439 shared object, and then that shared object 00:07:46.440 --> 00:07:50.639 is going to be loaded into Emacs system using require. 00:07:50.640 --> 00:07:53.119 So when I do require render core 00:07:53.120 --> 00:07:54.799 in one of the slides that I showed, 00:07:54.800 --> 00:07:58.439 I'm basically loading that shared object, 00:07:58.440 --> 00:08:00.516 and that shared object already has 00:08:00.517 --> 00:08:03.891 the compiled dynamic module functions and so on. 00:08:03.892 --> 00:08:06.308 But my blog will explain that better. 00:08:06.309 --> 00:08:10.016 Gotcha. I thought that was pretty clear. 00:08:10.017 --> 00:08:12.016 I'm looking forward to seeing that blog post 00:08:12.017 --> 00:08:13.641 and understanding what I glossed over 00:08:13.642 --> 00:08:15.860 trying to understand from that explanation. 00:08:15.861 --> 00:08:18.420 That was great. 00:08:18.421 --> 00:08:22.879 Can one look at PDF metadata with Emacs Reader? 00:08:22.880 --> 00:08:26.199 Can you do annotations? Does it understand forms? 00:08:26.200 --> 00:08:29.959 Can it handle encrypted PDFs? 00:08:29.960 --> 00:08:33.159 In other words, I think reading between the lines, 00:08:33.160 --> 00:08:34.279 wow, this is awesome. 00:08:34.280 --> 00:08:39.199 Is there anything I can't do? You're right. 00:08:39.200 --> 00:08:44.119 So Emacs Reader will be able to do all of those things. 00:08:44.120 --> 00:08:48.359 It can do annotations. It will be able to do forms. 00:08:48.360 --> 00:08:52.279 And we have an issue open for interpret PDFs. 00:08:52.280 --> 00:08:54.839 The thing is, right now we are struggling with 00:08:54.840 --> 00:08:58.759 making Emacs Reader be very efficient 00:08:58.760 --> 00:09:02.679 in terms of highlighting and text selection 00:09:02.680 --> 00:09:05.519 because of the challenges that I mentioned in the slides, 00:09:05.520 --> 00:09:07.959 so it will be able to do all that. 00:09:07.960 --> 00:09:10.959 Once we tackle the basic features 00:09:10.960 --> 00:09:18.599 down in an efficient manner. Gotcha. Um. 00:09:18.600 --> 00:09:24.119 Comment or questioner says, 00:09:24.120 --> 00:09:28.799 I installed Emacs Reader already as promised. Great job. 00:09:28.800 --> 00:09:34.879 How can I associate ODT files to open with Emacs Reader? 00:09:34.880 --> 00:09:38.479 You don't really need to do anything. 00:09:38.480 --> 00:09:40.599 You should be just able to do find file, 00:09:40.600 --> 00:09:42.959 Control X, Control F, and open. 00:09:42.960 --> 00:09:45.319 And it should open with Emacs Reader 00:09:45.320 --> 00:09:47.759 because we have an auto mode list, 00:09:47.760 --> 00:09:51.679 a list that takes an ODT file 00:09:51.680 --> 00:09:53.199 and opens it with reader mode. 00:09:53.200 --> 00:09:55.639 So you should just be able to do find file. 00:09:55.640 --> 00:09:56.879 If you're not able to do that, 00:09:56.880 --> 00:09:58.199 you should open Embug report. 00:09:58.200 --> 00:10:00.759 And I'll just mention 00:10:00.760 --> 00:10:03.239 we've got about 10 minutes left of our live Q&A, 00:10:03.240 --> 00:10:06.079 but if you're watching the stream, 00:10:06.080 --> 00:10:08.439 it's possible that we'll just keep going. 00:10:08.440 --> 00:10:10.799 The questions just keep coming, which I just love that. 00:10:10.800 --> 00:10:14.519 So feel free to join the BBB link 00:10:14.520 --> 00:10:17.439 that should have shown in the IRC chat. 00:10:17.440 --> 00:10:21.559 Jump in and we can take questions 00:10:21.560 --> 00:10:25.999 as long as Divya has steam for that. 00:10:26.000 --> 00:10:30.439 If a PDF file is open in Emacs Reader 00:10:30.440 --> 00:10:33.199 and I reintegrate the PDF with some changes, 00:10:33.200 --> 00:10:36.519 does the Emacs Reader refresh the PDF on its own 00:10:36.520 --> 00:10:38.919 or do I reload it? 00:10:38.920 --> 00:10:41.319 Right, that's also a really good question. 00:10:41.320 --> 00:10:44.599 So one answer is that it depends on 00:10:44.600 --> 00:10:46.079 how you change the PDF. 00:10:46.080 --> 00:10:50.839 So for example, if I just replaced the PDF 00:10:50.840 --> 00:10:52.639 with something else of the same name, 00:10:52.640 --> 00:10:55.799 Emacs will update it immediately. 00:10:55.800 --> 00:10:57.919 If you have auto revert mode on, 00:10:57.920 --> 00:10:59.119 it'll just revert the buffer 00:10:59.120 --> 00:11:01.879 and it'll reload the PDF really nicely. 00:11:01.880 --> 00:11:05.439 But if you're doing it something like LaTeX, 00:11:05.440 --> 00:11:07.399 where you're writing something in LaTeX 00:11:07.400 --> 00:11:10.519 and LaTeX is continuously producing the PDF, 00:11:10.520 --> 00:11:13.279 that needs SyncTeX integration. 00:11:13.280 --> 00:11:16.159 Because LaTeX, while it's producing the PDF, 00:11:16.160 --> 00:11:19.159 it does a lot of funky things. 00:11:19.160 --> 00:11:24.519 It does not provide a sort of renderable PDF all the time. 00:11:24.520 --> 00:11:28.679 So Emacs will sort of crash trying to 00:11:28.680 --> 00:11:31.679 basically render a PDF that is not ready yet. 00:11:31.680 --> 00:11:34.799 So we need SyncTex to sync 00:11:34.800 --> 00:11:37.279 with LaTeX to do that really nice. 00:11:37.280 --> 00:11:39.559 Okay, so we have to do some care 00:11:39.560 --> 00:11:41.319 and feeding of the exact timing 00:11:41.320 --> 00:11:46.879 if we have more of a continuous behind the curtains, so to speak. 00:11:46.880 --> 00:11:50.959 That makes a lot of sense to me. What are the challenges 00:11:50.960 --> 00:11:55.719 with integrating synctex and AucTex? 00:11:55.720 --> 00:11:58.919 This would be great to see as PDF handles as well, 00:11:58.920 --> 00:12:02.319 or PDF tools handles as well. Yeah, yeah. 00:12:02.320 --> 00:12:04.399 So, we have Synctex and Auctex planned. 00:12:04.400 --> 00:12:06.839 I don't really see any major obstacles 00:12:06.840 --> 00:12:08.679 for doing that, to be very honest. 00:12:08.680 --> 00:12:11.519 I think we can do it in a much simpler way 00:12:11.520 --> 00:12:12.479 than PDF Tools does. 00:12:12.480 --> 00:12:17.479 The only reason we haven't done it yet is because, again, 00:12:17.480 --> 00:12:20.479 we have more important highlighting 00:12:20.480 --> 00:12:24.399 and text selection and those features planned, 00:12:24.400 --> 00:12:32.919 but it's anticipated. Yeah. All right. This next question 00:12:32.920 --> 00:12:36.439 I love your presentation. Will you be giving another talk 00:12:36.440 --> 00:12:39.399 on the architecture you went over a deep dive on? 00:12:39.400 --> 00:12:44.919 That would be awesome. I'm not sure if an EmacsConf talk 00:12:44.920 --> 00:12:48.479 will be appropriate for this, but I do stream bi-weekly. 00:12:48.480 --> 00:12:52.599 So you're always welcome to come on my stream and ask, 00:12:52.600 --> 00:12:55.359 and I would be very happy to go deep into this. 00:12:55.360 --> 00:12:58.119 I'm looking forward to catching that myself. 00:12:58.120 --> 00:13:02.639 Thank you for the shout. Is there search functionality, 00:13:02.640 --> 00:13:05.319 something like isearch and occur? 00:13:05.320 --> 00:13:07.599 Yeah, we don't really have it, 00:13:07.600 --> 00:13:09.599 but this is the most immediate feature 00:13:09.600 --> 00:13:10.959 after we have text selection. 00:13:10.960 --> 00:13:12.399 So once we have text selection, 00:13:12.400 --> 00:13:14.359 once we're able to select the text, 00:13:14.360 --> 00:13:17.679 then we can have iSearch so that it can highlight the text. 00:13:17.680 --> 00:13:26.679 Yeah. Um, all right. And then, um, there's, I'm just gonna, 00:13:26.680 --> 00:13:28.799 I'll read out this question 00:13:28.800 --> 00:13:30.639 and then I have to do a little bookkeeping on the pad. 00:13:30.640 --> 00:13:35.639 Um, does the dynamic module, uh, prevent customization 00:13:35.640 --> 00:13:39.999 that Emacs usually provides advice, hooks, et cetera, 00:13:40.000 --> 00:13:44.359 or does everything just kind of 00:13:44.360 --> 00:13:46.559 No, if you have a dynamic module, 00:13:46.560 --> 00:13:49.279 it doesn't limit you into doing anything. 00:13:49.280 --> 00:13:52.839 You can do everything on the Elisp side that you want, 00:13:52.840 --> 00:13:55.719 and you only take care of certain things 00:13:55.720 --> 00:13:56.879 on the dynamic module side. 00:13:56.880 --> 00:13:57.999 If you're asking whether 00:13:58.000 --> 00:14:01.879 you can do advices, hooks, and all of that 00:14:01.880 --> 00:14:03.879 on the dynamic module itself, 00:14:03.880 --> 00:14:05.679 from the dynamic module itself, 00:14:05.680 --> 00:14:09.719 that's a bit tricky because something like 00:14:09.720 --> 00:14:13.999 Calling a macro or doing macros and dynamic modules 00:14:14.000 --> 00:14:18.119 is not really that nice You have to pretty much manually 00:14:18.120 --> 00:14:21.359 expand the macro yourself in the dynamic module 00:14:21.360 --> 00:14:23.839 so if you want to do it from the dynamic module, 00:14:23.840 --> 00:14:25.959 there's not much support right now, 00:14:25.960 --> 00:14:29.479 but you can do everything on the elisp side 00:14:29.480 --> 00:14:33.399 without touching the dynamic module. Got it 00:14:33.400 --> 00:14:38.279 So those are the questions that I see. 00:14:38.280 --> 00:14:39.999 I'm just going to take a quick peek, 00:14:40.000 --> 00:14:42.639 but let me invite you if you want to. 00:14:42.640 --> 00:14:45.999 We've got just about 5 minutes left 00:14:46.000 --> 00:14:48.239 and I will get carried away sometimes 00:14:48.240 --> 00:14:51.279 and fail to make this invitation before we cut away live, 00:14:51.280 --> 00:14:54.479 especially if we do keep going a bit. 00:14:54.480 --> 00:14:57.799 that you have live onto the stream. 00:14:57.800 --> 00:15:02.599 Of course, you don't have to do that. 00:15:02.600 --> 00:15:05.799 You said a lot in your presentation. 00:15:05.800 --> 00:15:12.199 No, I think mostly that's fine. 00:15:12.200 --> 00:15:13.679 I'm just really happy 00:15:13.680 --> 00:15:17.079 that people are interested in the package, 00:15:17.080 --> 00:15:19.879 and I would be glad to have contributors 00:15:19.880 --> 00:15:25.199 and viewers or anything. That would be nice. Awesome. 00:15:25.200 --> 00:15:28.879 So here comes one more question, 00:15:28.880 --> 00:15:31.959 or actually a couple more questions coming in. 00:15:31.960 --> 00:15:34.239 Following up on dynamic modules, 00:15:34.240 --> 00:15:38.479 do you usually create an Elisp shim 00:15:38.480 --> 00:15:40.399 from foreign function interface 00:15:40.400 --> 00:15:41.559 and then use them with Elisp? 00:15:41.560 --> 00:15:46.159 Yeah, so basically how you do is you write, 00:15:46.160 --> 00:15:49.639 let's say I have a C function 00:15:49.640 --> 00:15:51.399 that I've written in the dynamic module. 00:15:51.400 --> 00:15:52.879 It's a dynamic module function. 00:15:52.880 --> 00:15:54.639 And then when I'm trying to call 00:15:54.640 --> 00:15:56.039 the dynamic module function, 00:15:56.040 --> 00:15:58.999 most of the time, I don't call it like that. 00:15:59.000 --> 00:16:01.679 I wrap it inside a proper Elisp function 00:16:01.680 --> 00:16:03.559 and then call that Elisp function. 00:16:03.560 --> 00:16:08.279 So that's how I think it's better to do that because 00:16:08.280 --> 00:16:12.559 You can take care of certain cases 00:16:12.560 --> 00:16:15.199 on when you want the dynamic module function to be called. 00:16:15.200 --> 00:16:17.199 Maybe sometimes you don't want 00:16:17.200 --> 00:16:18.839 the dynamic module function 00:16:18.840 --> 00:16:19.879 to be called immediately. 00:16:19.880 --> 00:16:22.159 So it's better to wrap it. 00:16:22.160 --> 00:16:26.599 Yeah. Okay. So timing issues. Yeah. 00:16:26.600 --> 00:16:31.679 For the purposes of managing timing issues, 00:16:31.680 --> 00:16:34.319 that elisp shim is preferred. 00:16:34.320 --> 00:16:38.959 Yeah. Makes sense. Um. 00:16:38.960 --> 00:16:44.639 Uh, so question question here 00:16:44.640 --> 00:16:47.439 is searching for the person is searching for a roadmap. 00:16:47.440 --> 00:16:49.279 Is that already available as a feature? 00:16:49.280 --> 00:16:52.239 Searching is on the roadmap. 00:16:52.240 --> 00:16:56.559 It is not available yet as a feature, but it's on priority. 00:16:56.560 --> 00:16:59.839 I think you may have may have touched on that. 00:16:59.840 --> 00:17:06.559 Sorry. All right. Those are the questions that I see. 00:17:06.560 --> 00:17:08.279 We've got just a couple of minutes. 00:17:08.280 --> 00:17:10.399 I'm not sure if you have more you wanted to say, 00:17:10.400 --> 00:17:13.719 but I have to say how much I appreciate your talk, 00:17:13.720 --> 00:17:16.119 especially you jumping in live with us 00:17:16.120 --> 00:17:19.079 and just taking everything on the fly. 00:17:19.080 --> 00:17:24.559 I think this is a big part of what adds the energy, 00:17:24.560 --> 00:17:28.039 you in particular, just really dynamic speaker. 00:17:28.040 --> 00:17:31.479 Thank you. Thank you. Thank you. I enjoyed it as well. 00:17:31.480 --> 00:17:37.159 A person is, and I think this may have been touched on already, 00:17:37.160 --> 00:17:39.439 but let's maybe get into it more specifically. 00:17:39.440 --> 00:17:42.159 We've said that search is kind of 00:17:42.160 --> 00:17:44.719 a next up type of feature as things, 00:17:44.720 --> 00:17:48.159 as the current iteration stabilizes. 00:17:48.160 --> 00:17:52.239 Question was, you know, occur like, how would you? 00:17:52.240 --> 00:17:56.159 Totally. There will be occur searches. 00:17:56.160 --> 00:17:59.639 There will be isearch enabled, isearch. 00:17:59.640 --> 00:18:02.879 used to with PDF tools, 00:18:02.880 --> 00:18:06.439 we would be like parity with the features, 00:18:06.440 --> 00:18:08.719 all the features that you're used to with PDF tools. 00:18:08.720 --> 00:18:12.599 Um, so, uh, certainly occur anything 00:18:12.600 --> 00:18:15.679 that is important in Emacs with text 00:18:15.680 --> 00:18:17.359 and that can be done with PDFs. 00:18:17.360 --> 00:18:19.839 We really want to do that because, um, 00:18:19.840 --> 00:18:22.679 I want the package to be as knitted 00:18:22.680 --> 00:18:24.959 into Emacs ecosystem as possible. 00:18:24.960 --> 00:18:28.159 Okay. We'll see if we can get in this last question here. 00:18:28.160 --> 00:18:30.319 Do you have a timing expectation for ELPA? 00:18:30.320 --> 00:18:33.199 Uh, yeah, next major release essentially. 00:18:33.200 --> 00:18:35.279 So next major release is most likely 00:18:35.280 --> 00:18:37.319 going to be within a month or two. 00:18:37.320 --> 00:18:39.639 So once we have the next major release, we're going to be. 00:18:39.640 --> 00:18:43.479 Uh, timing couldn't be more perfect. 00:18:43.480 --> 00:18:45.519 Maybe this is a good, good point to break. 00:18:45.520 --> 00:18:47.759 We'll be cutting away to the next talk 00:18:47.760 --> 00:18:48.879 in just a couple of minutes. 00:18:48.880 --> 00:18:51.479 So let me say one more time how much 00:18:51.480 --> 00:18:52.959 on behalf of all the attendees 00:18:52.960 --> 00:18:54.959 and all the volunteers and all everybody, 00:18:54.960 --> 00:18:57.079 um, how much we appreciate your talks 00:18:57.080 --> 00:19:01.299 and, uh, your awesome contribution to the Emacs world. 00:19:01.300 --> 00:19:02.766 Thanks, Corwin.