The first question,
and I'm reading from the etherpad here,
is there a scope for integrating
the C library to Emacs itself
with MuPDF becoming an optional dependency?
Right, so integrating the C library into Emacs itself
is like having MuPDF inside Emacs source tree.
I don't think Emacs devs would be inclined to do that,
and I don't think we really need it.
Um, I think as it is, uh, Emacs
with doc view needs new tool, which is something you need
to install from new PDF anyways.
So, um, I think it is almost expected
that you install new PDF from system package manager.
Um, and I think that as it is, is better
because we don't really need to have
a whole PDF engine inside Emacs.
Um, Next question also from the pad,
the dynamic module some great,
and it's amazing that they've been there since 2017.
Why do you think they've been slowly
so slow to get adopted?
Is there a prior art with them? Right?
That's a good question.
Actually, I think 1 of the reasons is that.
Most of the time, I think people love Emacs
because they can do so much with Elisp.
I think certainly there is a bias
towards trying to do things with Elisp.
I think there's only a sort of specific class of problems
that you can solve with dynamic modules,
such as this, where you want to use a native library
to do something in a faster, better way.
I use that quite a lot.
There's of course libvterm, which uses a dynamic module
and it does it really well.
And I think there's another one, a plotting library
or package in Emacs that was using something from Python.
So, dynamic modules are good,
but I think they don't really come
to the surface level packages, your day-to-day packages,
because most of the day-to-day packages that we use in Emacs
can be done with Elisp. So, unless you really need
something system-level efficient,
Most of the time, you don't want to write C or C++ or something.
But there is actually a really nice Rust crate for native modules,
and there's a really nice Haskell package.
So there's actually really good support
for multiple languages.
So it's there, it's just not used as much. Yeah.
So what you're saying is
if Elisp weren't so simple to learn and easy to use
and so fully featured,
we'd get a lot more mileage
out of this super cool dynamic module feature.
Yeah. Cool I'll take I'll bring in the next question.
How how? How difficult is our PDF tools to install?
The questioner is installing it
using the built-in package manager
looking at the Emacs reader installation instructions
It doesn't necessarily cover
how how to install that easily
person is not using use package or straight and Okay.
Oh, and they say that you didn't
catch much of this in the presentation.
Okay, so you want me to skip that or should I answer?
It's your choice. If you would like to say more.
Yeah, I think just as a thing,
the reason I said PDF tools is difficult
is PDF tools has a huge list of dependencies.
The only thing Emacs Vita depends
on is new PDF, nothing else. There's a single dependency.
PDF tools depends on a lot of things
and they have their own server,
which is packaged as a system package,
which you don't really find everywhere.
And there's like systems, the new Linux systems
where the package is very difficult to build
because of so many dependencies.
So my goal was to sort of reduce
the number of dependencies.
And then right now it's very, it's sort of a key
to install Emacs Reader.
Once we go to GNU Elpa, it's just
going to be Emacs package install, just that.
Right now you have to do package VC
a bit. Boy, we get spoiled as
Emacs users. Everything just gets so easy
for us. It's like an IDE for our
whole machine. What tools did you use to measure the
memory usage between the three packages?
Yeah, that's a good question.
So during my development, I used mostly for debugging
purposes Valgrind. So Valgrind is a a set of suite
of debugging tools.
And one of the tools that it has is Massive.
It's a heap analyzer, heap profiler.
So Valgrind plus Massive,
and then there's a KDE package
called Massive Visualizer.
So I first get the Massive output using Valgrind,
and then put that output into Massive Visualizer.
That gives me the grasp.
Are there Emacs integrations for those components at all?
Does Valgrind have them?
I don't think so. I don't think so.
There's, yeah, there's I think a few packages
which do something with Massive,
but I don't think like they're maintained.
Yeah. Gotcha. Cool. Awesome opportunity
there for someone spunky.
How is conversion between Elisp and foreign language types?
For example, when interfacing with the C++ library
that makes heavy use of the C++ object system and templates.
Yeah, that's a good question.
So the go-to answer is the blog post that I wrote,
which is an extensive explanation
on how the internals of dynamic modules work.
The short answer is that basically what happens
is anything that is compatible with C-ABI
When you compile that language code,
so when I compile C++ code, I would have a particular API.
So we have a dynamic module API,
which is the emacs-module.h, the file that I showed.
You have to put that into your C++ package program
and then link it to...
So emacs-module.h is basically going to...
like use things in your Emacs installation
to interact with this C++ language. So it's basically FFI.
And what this gives you is that you can have things in C++.
So let's say you want to do multi-threading
the way I did system level multi-threading.
You can have C++ be responsible for the multi-threading.
but you want the output
of the multithreading to go into Emacs.
So then you write like a piece of C++ function,
which is going to be a dynamic module function.
A dynamic module function
is written in the language that you target,
that is C++ or C or Rust.
And then that is going to be compiled
into a share library like SO.
shared object, and then that shared object
is going to be loaded into Emacs system using require.
So when I do require render core
in one of the slides that I showed,
I'm basically loading that shared object,
and that shared object already has
the compiled dynamic module functions and so on.
But my blog will explain that better.
Gotcha. I thought that was pretty clear.
I'm looking forward to seeing that blog post
and understanding what I glossed over
trying to understand from that explanation.
That was great.
Can one look at PDF metadata with Emacs Reader?
Can you do annotations? Does it understand forms?
Can it handle encrypted PDFs?
In other words, I think reading between the lines,
wow, this is awesome.
Is there anything I can't do? You're right.
So Emacs Reader will be able to do all of those things.
It can do annotations. It will be able to do forms.
And we have an issue open for interpret PDFs.
The thing is, right now we are struggling with
making Emacs Reader be very efficient
in terms of highlighting and text selection
because of the challenges that I mentioned in the slides,
so it will be able to do all that.
Once we tackle the basic features
down in an efficient manner. Gotcha. Um.
Comment or questioner says,
I installed Emacs Reader already as promised. Great job.
How can I associate ODT files to open with Emacs Reader?
You don't really need to do anything.
You should be just able to do find file,
Control X, Control F, and open.
And it should open with Emacs Reader
because we have an auto mode list,
a list that takes an ODT file
and opens it with reader mode.
So you should just be able to do find file.
If you're not able to do that,
you should open Embug report.
And I'll just mention
we've got about 10 minutes left of our live Q&A,
but if you're watching the stream,
it's possible that we'll just keep going.
The questions just keep coming, which I just love that.
So feel free to join the BBB link
that should have shown in the IRC chat.
Jump in and we can take questions
as long as Divya has steam for that.
If a PDF file is open in Emacs Reader
and I reintegrate the PDF with some changes,
does the Emacs Reader refresh the PDF on its own
or do I reload it?
Right, that's also a really good question.
So one answer is that it depends on
how you change the PDF.
So for example, if I just replaced the PDF
with something else of the same name,
Emacs will update it immediately.
If you have auto revert mode on,
it'll just revert the buffer
and it'll reload the PDF really nicely.
But if you're doing it something like LaTeX,
where you're writing something in LaTeX
and LaTeX is continuously producing the PDF,
that needs SyncTeX integration.
Because LaTeX, while it's producing the PDF,
it does a lot of funky things.
It does not provide a sort of renderable PDF all the time.
So Emacs will sort of crash trying to
basically render a PDF that is not ready yet.
So we need SyncTex to sync
with LaTeX to do that really nice.
Okay, so we have to do some care
and feeding of the exact timing
if we have more of a continuous behind the curtains, so to speak.
That makes a lot of sense to me. What are the challenges
with integrating synctex and AucTex?
This would be great to see as PDF handles as well,
or PDF tools handles as well. Yeah, yeah.
So, we have Synctex and Auctex planned.
I don't really see any major obstacles
for doing that, to be very honest.
I think we can do it in a much simpler way
than PDF Tools does.
The only reason we haven't done it yet is because, again,
we have more important highlighting
and text selection and those features planned,
but it's anticipated. Yeah. All right. This next question
I love your presentation. Will you be giving another talk
on the architecture you went over a deep dive on?
That would be awesome. I'm not sure if an EmacsConf talk
will be appropriate for this, but I do stream bi-weekly.
So you're always welcome to come on my stream and ask,
and I would be very happy to go deep into this.
I'm looking forward to catching that myself.
Thank you for the shout. Is there search functionality,
something like isearch and occur?
Yeah, we don't really have it,
but this is the most immediate feature
after we have text selection.
So once we have text selection,
once we're able to select the text,
then we can have iSearch so that it can highlight the text.
Yeah. Um, all right. And then, um, there's, I'm just gonna,
I'll read out this question
and then I have to do a little bookkeeping on the pad.
Um, does the dynamic module, uh, prevent customization
that Emacs usually provides advice, hooks, et cetera,
or does everything just kind of
No, if you have a dynamic module,
it doesn't limit you into doing anything.
You can do everything on the Elisp side that you want,
and you only take care of certain things
on the dynamic module side.
If you're asking whether
you can do advices, hooks, and all of that
on the dynamic module itself,
from the dynamic module itself,
that's a bit tricky because something like
Calling a macro or doing macros and dynamic modules
is not really that nice You have to pretty much manually
expand the macro yourself in the dynamic module
so if you want to do it from the dynamic module,
there's not much support right now,
but you can do everything on the elisp side
without touching the dynamic module. Got it
So those are the questions that I see.
I'm just going to take a quick peek,
but let me invite you if you want to.
We've got just about 5 minutes left
and I will get carried away sometimes
and fail to make this invitation before we cut away live,
especially if we do keep going a bit.
that you have live onto the stream.
Of course, you don't have to do that.
You said a lot in your presentation.
No, I think mostly that's fine.
I'm just really happy
that people are interested in the package,
and I would be glad to have contributors
and viewers or anything. That would be nice. Awesome.
So here comes one more question,
or actually a couple more questions coming in.
Following up on dynamic modules,
do you usually create an Elisp shim
from foreign function interface
and then use them with Elisp?
Yeah, so basically how you do is you write,
let's say I have a C function
that I've written in the dynamic module.
It's a dynamic module function.
And then when I'm trying to call
the dynamic module function,
most of the time, I don't call it like that.
I wrap it inside a proper Elisp function
and then call that Elisp function.
So that's how I think it's better to do that because
You can take care of certain cases
on when you want the dynamic module function to be called.
Maybe sometimes you don't want
the dynamic module function
to be called immediately.
So it's better to wrap it.
Yeah. Okay. So timing issues. Yeah.
For the purposes of managing timing issues,
that elisp shim is preferred.
Yeah. Makes sense. Um.
Uh, so question question here
is searching for the person is searching for a roadmap.
Is that already available as a feature?
Searching is on the roadmap.
It is not available yet as a feature, but it's on priority.
I think you may have may have touched on that.
Sorry. All right. Those are the questions that I see.
We've got just a couple of minutes.
I'm not sure if you have more you wanted to say,
but I have to say how much I appreciate your talk,
especially you jumping in live with us
and just taking everything on the fly.
I think this is a big part of what adds the energy,
you in particular, just really dynamic speaker.
Thank you. Thank you. Thank you. I enjoyed it as well.
A person is, and I think this may have been touched on already,
but let's maybe get into it more specifically.
We've said that search is kind of
a next up type of feature as things,
as the current iteration stabilizes.
Question was, you know, occur like, how would you?
Totally. There will be occur searches.
There will be isearch enabled, isearch.
used to with PDF tools,
we would be like parity with the features,
all the features that you're used to with PDF tools.
Um, so, uh, certainly occur anything
that is important in Emacs with text
and that can be done with PDFs.
We really want to do that because, um,
I want the package to be as knitted
into Emacs ecosystem as possible.
Okay. We'll see if we can get in this last question here.
Do you have a timing expectation for ELPA?
Uh, yeah, next major release essentially.
So next major release is most likely
going to be within a month or two.
So once we have the next major release, we're going to be.
Uh, timing couldn't be more perfect.
Maybe this is a good, good point to break.
We'll be cutting away to the next talk
in just a couple of minutes.
So let me say one more time how much
on behalf of all the attendees
and all the volunteers and all everybody,
um, how much we appreciate your talks
and, uh, your awesome contribution to the Emacs world.
Thanks, Corwin.