Hello, everyone! Welcome to my talk,
"Getting detached from Emacs".
When I started to use Emacs,
I quickly gravitated towards using it
as much as I could.
Magit, Org, Dired,
a lot of new possibilities opened up.
However, there was a workflow
that was difficult for me to replace.
The problem for me was running shell commands
in sub-processes of Emacs,
which in some situations led me to stick to
using an external terminal.
These situations,
often revolved around long-running shell commands,
either on my local machine
or on a remote host.
When I was on a remote host,
I would also rely on using the program tmux
to be able to detach from the remote process.
My main concern at the time
was that I didn't want to having to avoid
restarting Emacs,
because I needed to wait for a process to complete.
However, there was of course a lot of things
I was missing out on by not using Emacs.
Therefore, my solution to resolving
the issue of occasionally having to leave Emacs
led me down the path of developing the package
Detached.
The package allows Emacs to delegate
the responsibility of creating processes
to the program dtach.
It also makes sure to write
the output of the process to a file,
which we will see later on how that is being used.
The package makes Emacs capable of
attaching to these processes
as well as managing them.
In the package, each process is called a session,
and inside of Emacs that is just
an object with properties
such as what command is being run,
what working directory is used,
where the output is stored, etc.
The important aspect is also that
these objects are being persistent,
so they are stored over time.
Today, I'm going to walk you through
how I use the package and what advantages
there are of treating processes like text.
I'm going to start by opening up M-x shell,
and I will run a command
to update my package manager.
Instead of pressing return,
I'll simply press shift return
to let Emacs delegate the execution
to the dtach program.
Emacs will immediately attach itself to the process,
and we therefore don't perceive any difference
from when running the command as a subprocess.
We now have the option though
to detach from the session,
and later on we can of course
reattach Emacs to the session.
For me, this addresses the core
of the problem that I had.
But let’s see what’s more
the new workflow inside of Emacs can bring.
The package supports multiple user interfaces
such as Eshell and Compile.
I will therefore switch to the Detached project,
and I will run the build command that I use.
I will run it with detached-compile
with the difference that
I can detach from the compilation.
One benefit of this new workflow is that
I can get a system notification shown up here
once a session has finished.
Previously, I was either forced to have
the terminal open so I could see it or hiding it,
but then risking having forgotten it.
How do we then see the output of a session?
Get the detached-list-sessions command,
and here we see
the command that we just built,
and we see the guix pull with an asterisk
indicating that it is continuously running.
If I press enter,
we will get the output of the session here.
And since it was run using compile,
we also have compilation mode enabled here,
so we could navigate between
potential warnings or errors.
And we see that there is a warning here.
One thing that
I have prepared here is that
if I open up the user interface,
we only see two sessions,
but that is because we applied a filter here.
So, we have actually the only sessions
that are created within the last 12 hours
and that are considered unique.
So, if I remove the uniqueness,
we also see that we have a previous build
running on the main branch.
So, I think that's typically normal
that you might have that.
And since the sessions can be considered text,
we can just mark these two and check,
does this warning exist on the main branch or not?
So, we can just diff these ones
and we see that the warning is only present
on the emacsconf branch.
Now, another benefit, in my opinion,
of the new way of working is that
I have these properties being displayed
in the user interface.
I can quickly see which commands are still running,
what hosts they are running on,
where they are running,
and for how long they have been running.
And if they have run,
how long did it take?
Occasionally, though, there might be
even more input needed to distinguish sessions.
So, what I typically do then is
press A to annotate the session,
I would add a "Warning found at emacsconf"
And then it will show up this annotation
in the echo area when I select the session.
Another great improvement of using these sessions
and consider them being text is,
now we also see the guix pull completed here.
Then we can also select and see that, okay,
there is a lot of updates in this command,
but let's not look at it now.
Let's instead remember that
previously last week
when I ran a guix pull,
I saw an Emacs package that looks interesting.
I rather don't remember its full name,
but it has something to do with collection.
So, what I then can do is
remove the 12 hour narrowing criteria,
and we can see here I got sessions ranging back
even to 28th of October.
Since these are just to be considered text,
I can--
now let's first narrow the sessions
to only show the ones that run guix pull.
Then I would narrow based on the output
containing a regular expression.
So, I remember it was something with collection.
And we got one hit.
Here it should be something with collection.
It was emacs-flymake-collection.
This is something that is a
very nice feature to have.
It doesn't create any overhead
of having these old sessions lying around
and occasionally, it can be interesting
to search through them as well.
So, for me, this is another example of
when bringing workflows into Emacs,
it often opens up new exciting possibilities.
Thanks a lot for listening.