We'll hit start recording.
All right, everyone.
Thanks, Andrew, for the great talk.
Super cool.
So now we have the live Q&A with Andrew.
Folks, you can start by asking your questions on the pad.
And we will also open up this big blue button
room in a few minutes for folks who
want to join here and ask questions here directly
to Andrew.
Thanks again, and take it away, Andrew.
OK, thank you.
Let's start from pod questions.
The first one, do I use this to have multiple configs
running
side by side for deep comparison?
Actually, I have two configurations primary here.
The first one is my main configuration
for the whole environment, which manages all the dot files.
And the second one is virtualenv-like.
It creates a new shell with some environment variables.
It's set inside it.
And it includes Emacs load path and other things
to make Emacs able to explore packages
inside this small environment.
And it removes all unnecessary environment variables,
which pollutes the environment.
So we have quite a small scope on which only Emacs
and a few other packages are available.
And as you saw at the end of the talk,
it was the example of such small environment
where I set up Emacs and all the dependencies from ground
up.
And actually, the similar thing I
use for development of my projects,
I have their project environments
made in the same way.
But usually, I use my primary Emacs instance.
But sometimes, it can be kind of mixed.
I have a few talks on my YouTube channel.
And you can check them out to get more information about it
.
The second--
Sorry.
One quick request, Andrew.
People are saying if you could maybe speak up a little bit
more so that they could hear you better, that would be
great.
OK, sure.
Thank you.
The second question.
Are you using Gix system or Gix on top of another distro?
If system, any tips?
I tried Gix system, but found getting started
was very difficult due to lack of Wi-Fi firmware
and incomplete documentation.
Personally, I use Gix system, Gix home,
Gix as a package manager, and also as a deployment tool
for a few services.
I started from very basic setup where I didn't have
anything
and build it piece by piece, including
building Gix home project.
So yeah, I use Gix system and all the things.
And talking about Wi-Fi, first option
is to buy a Wi-Fi adapter, which doesn't
require proprietary firmware.
And another option is finding the firmware and installing
it.
So it's up to you.
Everything actually is relatively easy,
and you can relatively easy find the way to do it.
The third question.
One of the issues I have had managing Emacs packages
with Gix is a conflict between Gix package
attest read-only and the Emacs package
attest hackable in real time.
Any suggestions to resolve this?
Yes, I have suggestions to resolve this.
Actually, it's true.
Everything which is in GNU store is read-only.
Everything which is built with Gix is almost set in stone,
and you can't edit it in real time.
But what I do--
can I share my screen?
One second.
I will press a few buttons, and I hope you will see it soon
.
Or maybe not so soon.
What I basically do, I take parts of the ELISP,
and I have them inside my scheme file
that I use to define my home environment and other things.
I don't know-- oh, OK.
That's it.
For example, here, this part is a scheme code.
But this part is pure ELISP code.
And I can use a direct region and use Emacs ELISP mode here
.
I will need parts, edit those parts, and select.
And when I'm fine with all the edits I did here--
for example, I can evaluate this form using
Control-X, Control-E, and so on.
And when I'm good with the results,
I can just save it and rebuild my whole home environment
and see it on a fresh Emacs instance load
from the new configuration and see if everything
works here as well.
So it's a little less interactive
than the usual Emacs configuration,
but still works quite well.
A question-- what is next for RD?
Actually, I have short-term plans and a little more
long-term plans.
Short-term plan is to make a first release
by the end of this year.
And this release-- actually, RD is quite usable currently,
but there is not much documentation and not
so many examples.
So I would like to prepare a documentation
getting started guide, live CD that you can use
for exploration purpose and for installation.
And also, I would like to find one or two maintainers which
will help with upcoming patches, because it's already
at least a few people who use it on a daily basis,
and they send a lot of patches.
And sometimes I have a hard time keeping up
with the speed of creating patches.
So the short-term plans is to make a first release
by the end of the year.
The long-term plans we can discuss later, I think.
And I will share them in RD announced mailing list.
OK, I think that's it for patterns.
Let me check RC.
I have-- OK, it seems that I answered all questions
that I found.
Let me know if something appears.
[AUDIO OUT]
Cool, thanks, Andrew.
And yeah, I think we still have over 10 minutes, maybe
12 minutes or so of live Q&A time on the stream.
So if people still have more questions,
please feel free to either add them on the pad,
or I think you should now also be
able to join this big blue button room to ask directly.
OK, I see one more question.
But I'm not sure what does it mean.
Do you use Emacs without this?
If so, for what purpose?
And how does it feel compared to RD?
OK, it's a question in general.
No, I don't use Emacs without RD.
Actually, all the Emacs configurations I use
is based on RD and built from that.
There is a way to add almost everything
you have in your basic Emacs configuration
to your RD Emacs configuration by creating a file
in your usual .config/emacsd directory
and loading it from your .init/el directory.
So you actually can have a very usual Emacs configuration
workflow in addition to RD.
But I don't use it because it's not a reproducible way
to do things because such workflow means
that I need to install packages separately somehow,
either with gix install or maybe some other package manager
,
or maybe this package manager, like package.al or straight.
al.
And it doesn't work well in the long term
because if I move such configuration, which
partially RD and partially usual Emacs configuration,
it will break on the new machine or maybe somewhere else
where I would like to move this configuration later.
OK.
We have a last slot for Q and A in the pad.
[LAUGHS]
Thank you, everyone, for joining this talk.
It was a pleasure to interview you.
I will be here for at least an hour or so
before I will go preparing to sleep.
So you can reach me by email, RC, here in big blue button
or some other way, probably.
Are there any plans to push things
from RD to gix main channel?
Actually, I have a commit access to gix,
and I try to upstream everything that
can be beneficial for both RD and gix to gix
and use it from the upstream.
But sometimes on some question, we didn't reach an
agreement,
or sometimes it's much easier to implement it
in a more rapid way, which probably I
wouldn't like to add to gix because it will require
too much time trying to fit to some gix.
So I keep it only in RD.
But the things that I see beneficial for both projects,
I try to share and to move them to gix.
Sounds great.
And another reminder for the folks
that you can join big blue button also directly.
If you want to type your questions into chat here
or just ask them over mic or with a microphone,
you can do that as well.
I think we still have about actually 10 or 12 more minutes.
I think I underestimated what we had.
So we still have plenty of time for questions.
[AUDIO OUT]
Added one more slot for Gondi in case someone
would like to fill it.
Thanks.
[AUDIO OUT]
How difficult is to add support for new packages to gix?
Have you found that's burdensome versus package L
or other in Emacs package management approach?
Actually, I find it quite easy to create packages for gix.
Maybe because I'm quite familiar with gix source code.
But maybe because it's not that difficult,
you just open a respective model like rd packages or gnu
packages in gix repository.
And you define the package you want.
And you define the dependencies you want.
Actually, a lot of packages already here in gix.
And some of the packages I package in rd
and later move to the gix.
So it's not hard to reference the dependencies
and find the dependencies already declared for you.
But what's more important, you can use dependencies not
only
on Emacs packages, but also on system packages.
For example, in my git package, you
can use a reference to git binary
and predefine the path to the git binary
inside a package configuration by fetching the source code
or something like that.
So any package that requires some system package to work
can use the system package as a dependency.
And it is a big benefit comparing
to other packaging solutions, which
can depend only on Elisp packages.
[AUDIO OUT]
Do you reckon rd is currently opinionated,
or is it a one-size-fits-all framework?
I would say it's quite opinionated.
I started from really bare-bone Emacs.
And I suffered for a while.
And I did features one by one very carefully,
crafting the current state of rd-emacs.
And it's, as I already said, vanilla flavored.
I try to stick with Emacs key bindings
to use built-in packages over external packages,
or use packages which are in the same way,
work in a similar manner to built-in packages.
So it's not usual.
It's not that user-friendly as Doom Emacs or Space Emacs.
It's more like a Prelude, or even more vanilla flavored
than Prelude.
But the good thing is that you can declare a feature
yourself.
And if you don't like something about rd-emacs provided
by features created by me or other contributors,
you can use the features declared by yourself
or by other people.
And one of the plans that I have according to rd,
which we are discussing on mailing list right now,
is contrib directory, which can include features provided
by different people.
For example, it's quite often asked to add evils support.
But I don't use evils.
And I don't want to maintain this package.
But I understand that many people
use such a way of interacting with text editor.
So it would be cool if someone who actually
using this feature will be maintaining it
in contrib directory.
And this feature will be sound with all other features
which
provided by rd itself.
And I think this way, it can cover more people needs
that it can cover right now.
So it will fit more people.
But the core rd won't be expanding its scope.
It will be quite focused.
How to get into rd is already documentation
and getting started guide.
There is a repository on source hut,
github.com/github/sourcehut/abcdw/rd.
And here you can see a very small readme,
which probably doesn't give you too much understanding of
what
is going on.
But it has all the necessary links.
It has a link to manual.
It has information of mailing lists,
which you can use to get help.
It has information about IRC channel in manual.
And you can join this channel and ask questions here.
And of course, you can take the source code
and take a look at it.
And currently, we have examples.
And here in examples, my whole configuration of my team
is present.
It's a little bit drafty.
I would like to reorganize this a little
to make it easier to follow.
And before first release, I hope I will do so.
But you can use it as an example, build on [INAUDIBLE]
Unfortunately, the documentation
is not very extensive.
So you can find it a little hard to follow.
Or maybe you can find it missing some important things.
But before first release, I hope the situation
will become a little better.
But anyway, you can always ask questions
until the documentation is ready.
Can you mix RD with custom Emacs init file?
Yes, you can.
I already mentioned it.
You can just define in your init.el
the statement that you load some other file
and use this file as your usual init.el file.
It will work completely OK.
And you can partially migrate to RD by using such approach.
But I don't recommend this approach in long term.
I already mentioned it.
But having usual init.el file and managing your
dependencies
using package.el or straight.el doesn't
cover system dependencies and other stuff, which
will lead to maybe irreproducible configurations.
[AUDIO OUT]
It's the heads up that we have about two more
minutes of live Q&A time.
And then after that, the stream will move on.
But people are welcome to continue asking questions,
either on the pad or IRC or by joining the Speakable button
room directly.
Thanks again, Andrew.
[AUDIO OUT]
Actually, I didn't expect so much questions.
And when I first took a look at the pad
and thought, OK, those six slots for Q&A will be enough.
Yeah, it's always a nice surprise, I guess.
[AUDIO OUT]
I hope everyone will be OK with jumping windows around,
because I switch between workspaces.
And it may be a little too noisy.
[AUDIO OUT]
Yeah, I think it's fine for the most part.
It was a bit of an interesting thing
trying to keep up the stream with it, because by default,
we maximize the speaker's webcam.
But then you're also sharing your screen
and sharing important details.
So we were also trying to get that on the stream as well.
But yeah, it was fine.
[AUDIO OUT]
OK, I think that there's no more questions.
And we can finish in this section.
All right, sounds good.
Thanks again, Andrew, for the great talk.
As a fellow Tiling Window Manager user and GNU gigs--
well, former committer, but still very much enthusiast,
I'm very much interested in this.
So I know I'll definitely be checking your work out.
So thanks again.
Thank you very much for organization
and all your contributions.
Very much appreciated.
Thank you.
Appreciate it.
All right, take care.
And we'll see you around.
Bye-bye.
Bye.
[AUDIO OUT]