[Speaker 0]: Well, we have about, I think,
10 or 15 minutes of on-stream Q&A time.
But if there's more questions than that,
people are welcome to stay.
If Mike has the time to answer some more,
then Awesome.
[Speaker 1]: Yeah, I will be around for the rest of the
conference. So I am spudpnds,
which is spud upside down on IRC,
if you want to hit me up on IRC.
Nice.
[Speaker 0]: I see we already have a question on the pad,
and it is, did you develop a variant of your
document for CentOS?
[Speaker 1]: I did not. I have not messed with any other
Red Hat distributions other than Fedora.
I would like to expand the document out to
Windows and to Mac OS as I think a lot of
people really want to build Emacs on those
platforms because it's much harder to get
Emacs binaries running on those platforms.
Although they're around on the internet it's
not as bad as it used to be,
but building Emacs is very,
a very fun thing to do.
And I encourage everybody to do that.
[Speaker 0]: Right. We're also getting comments from folks
here on BigBlueButton.
EXC or Matt saying, great talk,
good demonstration of what's possible.
And Aaron thanking Mike,
saying awesome presentation.
And they missed the first few minutes and
have to rewatch to get the portion that they
missed.
[Speaker 1]: I had a hard time cramming the entire talk
into 40 minutes. So I spoke quickly.
I have a feeling I may have left some folks
behind who weren't paying close attention.
So rewatching might help.
[Speaker 0]: Oh, nice.
[Speaker 1]: I noticed Matt said that he helps maintain
the shell functionality or Babel and last
March they added async evaluation into
session code blocks. Very cool,
especially when you're doing something that
takes a long time. It would be nice if Emacs
wasn't locked up. I will definitely have to
check that out. I use this technique at work
a lot, like when I write documents to how to
explain things to coworkers and such.
And 1 of the things I had to explain was how
to build AWS MySQL databases and replicas,
and how to build them with very specific
parameters to work with the system called
Vitesse. And when I was running that
document, building these kinds of MySQL
databases in AWS with lockup Emacs for 20,
25 minutes at a time. So,
yeah, I'm really excited about async
evaluation.
Totally. Oh yeah, Python mode I think has had
async for shell blocks for a while.
I think there's a third-party package at Elba
that adds async support for that.
But yeah, I explicitly wanted to make sure
that it would work with super vanilla stuff.
Oh, it's built in. I see.
Yeah, I didn't realize it was built in for
Python blocks. I'll have to check that out.
There's so much Emacs.
It's hard to wrap your head even around a
tiny portion of it. It's such a deep topic.
Looks like somebody in IRC said,
I can't wait to add some of this stuff to my
documents. And that really makes me happy.
I hope people go out and write literate Org
Mode documents that do amazing things.
When's the next talk? We have like,
[Speaker 0]: let's see. I think we have about 4 or 5
minutes live on stream for Q&A.
[Speaker 1]: Yeah, okay. Oh, here's the question.
Blaine asks, are you running Emacs from the
host machine? And yeah,
so I'm running Emacs on the exact same
machine that I'm building Emacs on.
And I had first thought about doing that over
Tramp. And I thought that would be a very
cool demo to show how you could do that
remotely on Tramp so you didn't need Emacs on
the host machine. But I decided it would be a
lot easier, and as I ran into a deadline to
get the talk completed,
I abandoned that notion for the
straightforward approach.
But ideally, I would spin up virtual machines
and then using the Org Mode document and
having Org Mode reach out to those machines
via SSH and Tramp.
Oh yeah, there's also a little bit of
discussion on IRC about org macros and how
they made their way into the document.
And I remember when I first discovered org
macros by reading the org mode documentation,
I was really excited because I thought I
could limit a lot of the boilerplate I end up
typing. But as we discussed,
ORD macros, I think, only work in 1 context
in your ORD mode document,
and I think that's in the pros section.
So You can't resolve a macro inside a header
arg, for example, or inside an options block.
It would be awesome if macros worked
everywhere, but I'm happy to have them just
as they are now.
[Speaker 0]: Indeed, they're very convenient.
[Speaker 1]: And Blaine also says, thank you for showing
what's possible with literate documentation.
This is mind-blowing. Yeah,
I think so too. I first saw this technique in
Howard's video, Literate DevOps,
and I remember I was just picking up parts of
my mind after it exploded after having
watched that video. So I wanted to do some of
it myself, and that's where I came up with a
couple different approaches to that.
It's not just for, you know,
making literate Emacs configurations.
[Speaker 0]: For Sure. We have another remark slash
question on the pad. Someone saying great
presentation. The preparation is outstanding.
And for someone like me that never touched
the org-mux side of Emacs,
What do you feel is the more complex part to
tackle? You made it seem simple,
but the complexity there.
[Speaker 1]: Yeah. Just getting all of the configuration
set up the way you want it is the hardest
part. So some of the defaults are,
you know, they don't look good when you
render them out in LaTeX and finally PDF.
And there's a lot of work to be done to tweak
the LaTeX environment so it looks as pretty
as you might want it. And then just Org Mode
has a lot of knobs that you can tune,
and they have a pretty large impact on how
your document is exported.
So I think the hardest part is just knowing
what's possible and knowing where all the
knobs are to tune and twist.
[Speaker 0]: Got another question on the pad.
And I think we have about a minute or so on
the stream. So I'll read this question as
well. But folks, you're welcome to continue
on the pad or just come join here on BBB
after myself and the stream move on to the
next talk. Yeah, and the next question is,
how do you normally debug,
for example, view the logs or see failed
statuses when the commands in the source
blocks fail, especially if they output lots
and lots of logs, and you need to see the
full history of the build.
[Speaker 1]: Yeah, so I see it in the messages buffer
whenever I export a document.
If there's a failure, that's typically where
it's written to. And I will actually kill the
messages buffer before I export so I know
that only the messages in the buffer are for
my given export and I mentioned that
debugging trick where you name all of your
org-mode source blocks So if there is a
problem in 1 of the blocks,
it'll actually tell you what the block,
the name of the block the error occurred in.
If you don't do that, it just gives you a
position number in the buffer.
And whenever I tried to convert those
position numbers to actual places where the
error occurred, it was never exactly where I
suspected it would be.
So I found that very difficult in debugging.
So the only real debugging tip I have is name
your source blocks, even if you don't refer
to them later.
[Speaker 0]: I think that's all the time we have on
stream. And I also have to drop as well.
But thanks again so much,
Mike. And folks are welcome to come here and
continue discussion here.
Thanks again.
[Speaker 1]: You
Thank
[Speaker 0]: you
[Speaker 1]: for
watching. You
you