diff options
Diffstat (limited to '')
| -rw-r--r-- | 2025/captions/emacsconf-2025-reader--an-introduction-to-the-emacs-reader--divy--answers.vtt | 1081 |
1 files changed, 1081 insertions, 0 deletions
diff --git a/2025/captions/emacsconf-2025-reader--an-introduction-to-the-emacs-reader--divy--answers.vtt b/2025/captions/emacsconf-2025-reader--an-introduction-to-the-emacs-reader--divy--answers.vtt new file mode 100644 index 00000000..b9dae5b5 --- /dev/null +++ b/2025/captions/emacsconf-2025-reader--an-introduction-to-the-emacs-reader--divy--answers.vtt @@ -0,0 +1,1081 @@ +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. |