path: root/2025/captions/emacsconf-2025-reader--an-introduction-to-the-emacs-reader--divy--answers.vtt

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.