WEBVTT

00:00.000 --> 00:02.360
Thank you for the great talk, Niklas.

00:02.360 --> 00:05.040
And yes, the Q&A is now open.

00:05.040 --> 00:09.320
Folks, feel free to post your questions on the pattern IRC.

00:09.320 --> 00:10.900
And after a minute or two, we'll also

00:10.900 --> 00:12.680
open up this big blue button for people

00:12.680 --> 00:15.820
who might prefer to come join Niklas here directly

00:15.820 --> 00:17.680
and ask the questions here.

00:17.680 --> 00:20.240
Niklas, take it away.

00:20.240 --> 00:21.000
All right.

00:21.000 --> 00:21.720
Thank you.

00:21.720 --> 00:25.040
And thanks for having me.

00:25.040 --> 00:28.720
Yeah, maybe I'll go ahead and read some questions

00:28.720 --> 00:32.880
that have popped up in the formula here then.

00:32.880 --> 00:37.440
So the first question is, can it replace SSH plus TMAX

00:37.440 --> 00:42.280
for persistent sessions on remote hosts?

00:42.280 --> 00:46.440
So currently, I would say it does not

00:46.440 --> 00:49.720
support that because it is designed

00:49.720 --> 00:53.440
to only run a single command inside a session.

00:53.440 --> 00:59.920
And when that finishes, it reports back.

00:59.920 --> 01:01.640
But I have played with the idea.

01:01.640 --> 01:04.480
I think it should be possible to do.

01:04.480 --> 01:08.640
But I wanted to start off and polish the experience

01:08.640 --> 01:12.720
with a single command first.

01:12.720 --> 01:16.880
And secondly, there is a question.

01:16.880 --> 01:20.880
I see integration with projectile in the README.

01:20.880 --> 01:23.960
Does it also integrate with project.io?

01:28.400 --> 01:30.200
Yeah, good question.

01:30.200 --> 01:31.840
It doesn't.

01:31.840 --> 01:37.920
I haven't added any explicit support for it

01:37.920 --> 01:43.880
because I typically run detached compiling in the project

01:43.880 --> 01:49.160
root with my own command using project behind the scenes.

01:49.160 --> 01:51.880
But I guess project has a command for it now.

01:51.880 --> 02:21.840
So yeah, it should be very easy to add support for that.

02:21.840 --> 02:28.000
And I could also mention that could be one thing related

02:28.000 --> 02:31.480
to the first questionnaire of using kind of persistent

02:31.480 --> 02:37.560
sessions, that it would be interesting to see if,

02:37.560 --> 02:44.000
for example, I occasionally run Python REPL in Emacs.

02:44.000 --> 02:48.000
And if I could get that one to launch using detach,

02:48.000 --> 02:52.960
so I could restart Emacs and reattach to the REPL

02:52.960 --> 02:57.920
or also use it for situations where I have used the REPL

02:57.920 --> 03:02.000
to, let's say, experiment with, I don't know,

03:02.000 --> 03:04.720
some NumPy function, how that works.

03:04.720 --> 03:10.400
And if I use detach for that, it would automatically

03:10.400 --> 03:12.920
log then the whole session.

03:12.920 --> 03:15.360
And I would have it accessible.

03:15.360 --> 03:19.560
So I could search for it in retrospect

03:19.560 --> 03:23.880
and retrieve the log and see, OK, I ran this command.

03:23.880 --> 03:26.760
This happened, or basically.

03:32.680 --> 03:35.320
So then there is a question.

03:35.320 --> 03:36.600
Can you?

03:36.600 --> 03:37.360
Oh, OK.

03:37.360 --> 03:38.800
I'll read the other one.

03:38.800 --> 03:43.400
No, there is two in there.

03:46.920 --> 03:48.040
It's ongoing.

03:48.040 --> 03:51.240
I'll wait for them.

03:51.240 --> 03:52.920
So the first question is, can you

03:52.920 --> 03:56.520
detach a session from shell mode and reattach

03:56.520 --> 04:01.920
from eshell vterm mode or start a compile in a shell mode

04:01.920 --> 04:09.120
and attach it from compilation mode?

04:09.120 --> 04:16.240
Yeah, so you can attach at the moment

04:16.240 --> 04:20.400
or reattach in shell mode, eshell vterm.

04:20.400 --> 04:25.680
That is no problem.

04:25.680 --> 04:33.880
Currently, I don't have support for attaching in compilation

04:33.880 --> 04:34.720
mode.

04:34.720 --> 04:39.040
So the way the package is built is

04:39.040 --> 04:44.280
that when the session is started,

04:44.280 --> 04:51.240
there is a variable that gets inserted into the session.

04:51.240 --> 04:56.280
And it describes how the session would handle,

04:56.280 --> 05:01.720
for example, attaching to it or viewing the output, et cetera.

05:04.480 --> 05:12.560
But these are the things that I want to primarily focus

05:12.560 --> 05:17.680
in the near future, so making it easier to, for example,

05:17.680 --> 05:21.040
have a buffer up where you're attached to a session.

05:21.040 --> 05:25.680
You could run a key binding to switch

05:25.680 --> 05:29.000
to the view mode of that session.

05:29.000 --> 05:32.800
You get the full output, and then you could view it.

05:32.800 --> 05:37.200
You can switch back to the attached version, which

05:37.200 --> 05:40.560
just shows a brief context and then continues on

05:40.560 --> 05:45.120
with the current output from the session.

05:45.120 --> 05:50.640
Question number four here is, how do you talk to detach?

05:50.640 --> 05:54.480
Could it be feasible to run a child emacs instead

05:54.480 --> 05:56.360
of detach?

05:56.360 --> 05:58.800
Would it make sense?

05:58.800 --> 06:02.520
Better communication, maybe.

06:02.520 --> 06:08.560
So the way the talk with detach is done

06:08.560 --> 06:11.680
is, I would say, very simple.

06:11.680 --> 06:19.480
Detach the program supports basic instructions

06:19.480 --> 06:25.320
like detach dash a to attach, or yeah, that's basically it.

06:28.080 --> 06:32.760
And that is all that's being used under the hood.

06:32.760 --> 06:37.280
And of course, it uses its C flag

06:37.280 --> 06:47.240
to create and attach when a session is started, or the dash

06:47.240 --> 06:52.440
n to start the session in kind of detached mode.

06:52.440 --> 06:55.440
So it runs without emacs being attached to it.

06:58.240 --> 07:05.720
Currently, I don't think I've seen any need for a child emacs

07:05.720 --> 07:08.920
need for better communication.

07:08.920 --> 07:15.400
But if people have ideas about what could be done,

07:15.400 --> 07:19.280
if it was added, yeah, that would be great.

07:19.280 --> 07:20.960
So maybe that could be a follow up

07:20.960 --> 07:24.640
if you got ideas on how to improve it.

07:24.640 --> 07:33.160
Yeah, so I'm not sure if the emacs child, yeah,

07:33.160 --> 07:36.360
I think if I got a better idea about what

07:36.360 --> 07:39.120
the person would like to achieve with it,

07:39.120 --> 07:43.000
then maybe I could understand the question better there.

07:45.880 --> 07:49.480
So another question is, how does it handle processes

07:49.480 --> 07:52.560
that require you to do that?

07:52.560 --> 07:55.440
So processes that require user input,

07:55.440 --> 07:59.080
usually type yes, no, et cetera.

07:59.080 --> 08:05.600
MetaX compiles great, but can't handle user input.

08:05.600 --> 08:16.600
Yeah, so it's very simple behind the scenes.

08:16.600 --> 08:21.320
It depends on what interface you use for attaching emacs

08:21.320 --> 08:23.160
to that process.

08:23.160 --> 08:27.680
So as the person says, if it's MetaX compiled,

08:27.680 --> 08:32.160
then probably it doesn't handle it.

08:32.160 --> 08:40.080
So in that case, I guess I would have started it

08:40.080 --> 08:42.680
from the shell.

08:42.680 --> 08:46.960
If there is a question, you need to type yes or no,

08:46.960 --> 08:53.000
then you can just type it and maybe detach from it.

08:53.000 --> 08:56.400
Or if you end up in a situation where

08:56.400 --> 09:00.080
you started with MetaX compile, but then it has the question,

09:00.080 --> 09:04.400
I guess you could always pop up a shell attached

09:04.400 --> 09:07.080
to the session, and you will get the question there.

09:07.080 --> 09:11.480
You press whatever answer you'd like,

09:11.480 --> 09:20.000
and then detach from that user interface.

09:20.000 --> 09:23.480
So another question is, can you rerun a command session,

09:23.480 --> 09:25.880
but in another directory?

09:28.560 --> 09:33.360
Yeah, you can't do that at the moment.

09:33.360 --> 09:38.120
I haven't really found a need for it.

09:38.120 --> 09:46.000
So typically, as I have been using detach,

09:46.000 --> 09:52.680
now when it has a persistent storage of the sessions,

09:52.680 --> 09:57.040
it becomes rather natural that once I've run it once,

09:57.040 --> 10:07.120
I can just rerun it later in the same directory.

10:07.120 --> 10:11.400
But maybe this is a feature that should be added.

10:11.400 --> 10:16.840
It's maybe a common use case.

10:16.840 --> 10:22.120
One thing that I added on top of the rerun

10:22.120 --> 10:25.280
is like an edit and rerun for those situations

10:25.280 --> 10:30.240
where I maybe run some compilation,

10:30.240 --> 10:34.960
but with the compilation flag set to opt,

10:34.960 --> 10:37.680
and then I want to rerun the exact same command

10:37.680 --> 10:43.600
in the same directory, but with it set to dbg instead

10:43.600 --> 10:44.520
for debugging.

10:44.520 --> 10:48.600
And then instead of pressing R to rerun, I press E.

10:48.600 --> 10:53.400
Then I get a prompt with the current command,

10:53.400 --> 10:57.640
and then I can add it, and it will rerun that.

10:57.640 --> 11:00.920
So maybe something similar for another directory

11:00.920 --> 11:05.320
could be added.

11:22.720 --> 11:23.200
Cool.

11:23.200 --> 11:27.200
I think we still have about 13 or 14 more minutes of live Q&A

11:27.200 --> 11:29.840
time on stream, so if folks do have more questions

11:29.840 --> 11:32.440
about this talk from Nicolas, please

11:32.440 --> 11:33.960
feel free to put them on the pad,

11:33.960 --> 11:36.560
or come join here on the big blue button and ask here.

11:40.400 --> 11:41.320
Yeah.

11:41.320 --> 11:47.600
And I also want to mention that if you realize later

11:47.600 --> 11:50.000
you have a question or a suggestion,

11:50.000 --> 11:57.200
feel free to contact me or create a new post

11:57.200 --> 12:00.960
on the mailing list for the project.

12:00.960 --> 12:02.720
That's much appreciated.

12:07.160 --> 12:09.720
Sounds good.

12:09.720 --> 12:10.240
Yeah.

12:10.240 --> 12:22.880
So then there is a question incoming.

12:22.880 --> 12:30.320
So what are some other places where this might be useful?

12:30.320 --> 12:32.760
And you, for me, fetching that question

12:32.760 --> 12:40.480
is, what are some other places where this might be useful?

12:40.480 --> 12:46.320
And you, for me, fetching mail, get processes started by magic.

12:46.320 --> 12:48.880
What things would you like to see working

12:48.880 --> 12:52.560
in a one to two-year time frame?

12:55.040 --> 12:58.520
Yeah, that's a good question.

12:58.520 --> 13:01.800
I think there are these situations.

13:01.800 --> 13:04.800
One of the things that I ran into yesterday

13:04.800 --> 13:11.320
was that I was trying to use EMMS to connect

13:11.320 --> 13:14.560
to the stream for Emacs Conv.

13:14.560 --> 13:17.640
And that was working fine.

13:17.640 --> 13:22.040
It was using MPV in the background.

13:22.040 --> 13:25.280
But then I did some modifications to my Emacs

13:25.280 --> 13:30.120
and wanted to restart it, and then the stream died.

13:30.120 --> 13:35.600
Kind of those situations where I found it valuable,

13:35.600 --> 13:41.800
I added support for the D-RED R-Sync package,

13:41.800 --> 13:44.440
for example, that I use occasionally

13:44.440 --> 13:51.480
to copy things to a remote server

13:51.480 --> 13:52.960
or from a remote server.

13:52.960 --> 13:56.280
And yeah, that was always something

13:56.280 --> 14:00.240
that I thought could benefit from it.

14:00.240 --> 14:08.000
So I would ideally like to see if it

14:08.000 --> 14:13.080
can be used for more of these processes.

14:15.680 --> 14:21.600
I guess maybe I should get in contact

14:21.600 --> 14:27.480
with some of the devs to see if they have ideas on how this

14:27.480 --> 14:33.360
could be incorporated better with Emacs.

14:33.360 --> 14:36.440
Because so far, it was kind of straightforward

14:36.440 --> 14:41.000
to get it to work with Shell or Compile.

14:41.000 --> 14:47.360
But it hacks around the current implementation

14:47.360 --> 14:48.760
to make it use Detach.

14:48.760 --> 14:55.360
And if I wanted it to be used in many more places,

14:55.360 --> 14:58.560
it feels like it would be maybe not the best way

14:58.560 --> 15:07.440
to have a lot of advices being added to the various functions.

15:07.440 --> 15:12.720
But yeah, definitely, it would be really cool

15:12.720 --> 15:17.760
if that could be worked on properly

15:17.760 --> 15:22.880
so that once I've managed to get the workflow

15:22.880 --> 15:27.080
for its current implementation a little bit more polished,

15:27.080 --> 15:38.600
I will try to look into this and also see what is possible.

15:38.600 --> 15:42.080
I don't know if there are any limitations

15:42.080 --> 15:49.360
with my current approach that I need some more expertise on.

16:12.080 --> 16:39.760
Yeah, so if there is no other questions, I'll

16:39.760 --> 16:53.960
OK, there is another question.

16:53.960 --> 16:59.720
OK, a general topic here.

16:59.720 --> 17:02.520
What are you currently excited about in Emacs?

17:02.520 --> 17:15.520
Well, I'm really excited about the TreeSitter

17:15.520 --> 17:21.120
that was just added to Emacs 29.

17:21.120 --> 17:27.240
I haven't gotten around to use that yet.

17:27.240 --> 17:29.640
But I think it looks very promising.

17:29.640 --> 17:37.440
And I'm a big fan of structural editing

17:37.440 --> 17:39.040
that you can use in Lisp.

17:39.040 --> 17:42.600
So if this opens up the possibility

17:42.600 --> 17:47.880
to be able to use that more in other languages,

17:47.880 --> 17:49.000
that would be really cool.

17:49.000 --> 17:56.880
Otherwise, I'm generally excited about how

17:56.880 --> 18:01.880
the program is developing.

18:01.880 --> 18:05.040
I think there has been a lot of great additions

18:05.040 --> 18:11.720
in these last couple of versions of the program.

18:11.720 --> 18:13.680
So it's cool to see.

18:13.680 --> 18:22.640
And also how the Emacs Conf has been continuing

18:22.640 --> 18:27.760
and being an annual thing and also growing,

18:27.760 --> 18:33.280
adding this new layout with the general track

18:33.280 --> 18:34.280
and development track.

18:34.280 --> 18:35.080
I think it's great.

18:39.080 --> 18:39.560
Thanks.

18:39.560 --> 18:41.040
Yeah, it's been interesting.

18:41.040 --> 18:46.800
Emacs itself, I feel like the Emacs-Devel mailing list

18:46.800 --> 18:50.520
has been growing in traffic over the years.

18:50.520 --> 18:52.280
I've been subscribed for a couple of years.

18:52.280 --> 18:56.200
And more recently, I'm just seeing more and more

18:56.200 --> 18:57.600
incoming emails from Emacs-Devel,

18:57.600 --> 19:00.000
which is always cool.

19:00.000 --> 19:02.680
Yeah, and like you said with Emacs Conf,

19:02.680 --> 19:05.800
yeah, we've been growing, thankfully.

19:05.800 --> 19:07.680
And this year, we've experimented

19:07.680 --> 19:09.280
with having two tracks, which I think

19:09.280 --> 19:12.280
has turned out pretty well, pretty great.

19:12.280 --> 19:15.600
Because we don't have to try to squeeze in all the talks

19:15.600 --> 19:19.080
so tightly and be able to give proper Q&A time,

19:19.080 --> 19:20.960
like this one, I think, which is pretty great.

19:20.960 --> 19:23.280
So yeah, very glad to hear and see it.

19:27.400 --> 19:33.400
Yeah, and maybe I should mention now

19:33.400 --> 19:41.320
that I know that the E-Shell talk is coming up by Howard,

19:41.320 --> 19:45.880
that I discovered there is a kind of a bug

19:45.880 --> 19:50.320
in the detached implementation.

19:50.320 --> 19:56.320
So it doesn't handle properly the way E-Shell

19:56.320 --> 20:07.040
seems to communicate when you quote some text in a shell

20:07.040 --> 20:07.920
command.

20:07.920 --> 20:11.480
If you have been using quotes, it

20:11.480 --> 20:14.840
seems to be added as text properties that

20:14.840 --> 20:16.240
gets into detached.

20:16.240 --> 20:20.040
And I didn't know about that, but detached

20:20.040 --> 20:22.080
is not picking that up.

20:22.080 --> 20:28.040
So if you try to run something similar to Echo

20:28.040 --> 20:33.960
and quotation marks, Niklas, then yeah, it will not

20:33.960 --> 20:35.360
run it with quotation marks.

20:35.360 --> 20:38.200
So I guess for Echo, it might work,

20:38.200 --> 20:42.280
but other commands, it can fail.

20:42.280 --> 20:45.760
So just be aware about that.

20:45.760 --> 20:49.360
I guess that's on the priority list to fix.

20:49.360 --> 20:50.280
Interesting.

20:50.280 --> 20:51.960
Yeah, for sure.

20:51.960 --> 20:54.720
I guess folks can look forward to that getting hopefully fixed

20:54.720 --> 20:59.080
in the near future or at some point.

20:59.080 --> 21:05.640
Yeah, and I could add that maybe something

21:05.640 --> 21:15.240
that is in between this request for persistent sessions

21:15.240 --> 21:20.040
is that currently, you can use detached in a way

21:20.040 --> 21:23.360
so it creates like it runs the session.

21:23.360 --> 21:28.400
And once that finish, you use its callback

21:28.400 --> 21:32.920
to generate a new session, which runs some other command.

21:32.920 --> 21:41.240
So you can chain detached sessions that way.

21:41.240 --> 21:47.680
I wanted to improve on how that has been implemented

21:47.680 --> 21:55.040
so that you can more easily start these changed sessions

21:55.040 --> 21:58.520
and that they would show up in the user interface.

21:58.520 --> 22:05.120
And maybe if you rerun the top of the chain,

22:05.120 --> 22:12.720
it will actually start all these sessions that way.

22:12.720 --> 22:16.680
I have some use cases personally where

22:16.680 --> 22:22.200
for the time being, before running an executable,

22:22.200 --> 22:24.920
I actually need to run a different build command

22:24.920 --> 22:27.160
than I normally do.

22:27.160 --> 22:32.880
And I keep forgetting that, and then that fails.

22:32.880 --> 22:35.960
And it would be great to just be able to.

22:35.960 --> 22:40.440
I mean, you could always have that first command

22:40.440 --> 22:48.240
and then and and the other one, but it doesn't look as nice.

22:48.240 --> 22:53.960
And it would be nice to be able to see that, OK, this has been

22:53.960 --> 22:57.720
this is currently running, but in the next once that's

22:57.720 --> 23:02.080
finished, it will keep on running this one.

23:02.080 --> 23:05.440
So that's something I plan to add support for.

23:05.440 --> 23:09.360
It sounds good.

23:09.360 --> 23:10.120
That would be nice.

23:14.080 --> 23:17.200
Yeah, I would like that as well.

23:17.200 --> 23:21.360
So I have an incentive.

23:21.360 --> 23:41.720
Yeah, also not to completely derail this,

23:41.720 --> 23:45.120
but I mean, I don't think there are any questions as of now.

23:45.120 --> 23:46.800
So I can maybe mention this.

23:46.800 --> 23:48.320
Someone pinged me on IRC.

23:48.320 --> 23:50.640
Well, someone, Shoushin, good friend.

23:50.640 --> 23:53.920
And the creator, actually, of the musics

23:53.920 --> 23:56.400
that we've been using at Emacs Conf between for our lunch

23:56.400 --> 23:58.880
breaks and here and there, he mentioned

23:58.880 --> 24:01.080
that he likes this FSF shirt.

24:03.960 --> 24:05.720
Yeah, it's nice.

24:05.720 --> 24:06.200
Thanks.

24:06.200 --> 24:10.120
Yeah, it's I think from a year or so ago.

24:10.120 --> 24:14.200
It was put up for FSF's 35th birthday.

24:14.200 --> 24:17.160
And yeah, it's also what it says, FSF 35.

24:17.160 --> 24:20.280
Yeah, I'm not sure if it's still available on their shop,

24:20.280 --> 24:22.360
but yeah, you might be able to find it there.

24:25.880 --> 24:27.160
Nice.

24:27.160 --> 24:31.080
So they have their own shop?

24:31.080 --> 24:32.000
Yeah, so there is.

24:32.000 --> 24:33.520
You can buy merch or?

24:33.520 --> 24:34.480
Yeah, exactly.

24:34.480 --> 24:37.080
There is shop.fsf.org, and they have

24:37.080 --> 24:41.880
a bunch of different goodies and things, merchandise.

24:41.880 --> 24:44.440
They have shirts like this one, but they also

24:44.440 --> 24:45.920
have a lot of other stuff.

24:45.920 --> 24:47.960
They have this one, but they also

24:47.960 --> 24:51.200
sell things like printed versions of the Emacs user

24:51.200 --> 24:54.840
manual, which is particularly relevant for us.

24:54.840 --> 24:57.680
Yeah, and Emacs stickers.

24:57.680 --> 24:59.280
I think also sell pins and such.

24:59.280 --> 25:02.280
So yeah, I mean, if you are interested in Emacs

25:02.280 --> 25:06.200
or new on FSF, it might be worth checking out.

25:06.200 --> 25:08.680
Yeah, thanks for the tip.

25:08.680 --> 25:11.360
Yeah.

25:11.360 --> 25:14.520
Cool, and I think we have about one more minute of live Q&A

25:14.520 --> 25:17.880
time if folks have any questions,

25:17.880 --> 25:23.520
any last-minute ones, you're welcome to send it in.

25:23.520 --> 25:26.880
I guess there is, uh-huh.

25:26.880 --> 25:32.240
OK, yeah, this one got added from Karfik.

25:32.240 --> 25:32.740
Yeah.

25:38.600 --> 25:41.560
Yeah, otherwise, if there's no further questions,

25:41.560 --> 25:44.200
maybe we wrap it up.

25:44.200 --> 25:45.320
Sure, sounds good.

25:45.320 --> 25:46.880
Yeah, I don't see any new questions.

25:46.880 --> 25:49.560
So yeah, thanks again, Nicholas, for the great talk

25:49.560 --> 25:52.640
and for sticking around and doing the live Q&A.

25:52.640 --> 25:54.360
It's much appreciated, and look forward

25:54.360 --> 26:01.080
to seeing the upcoming developments in Detached.

26:01.080 --> 26:03.400
Thank you, and thanks for having me.

26:03.400 --> 26:06.760
Cheers, very glad to see you around.

26:06.760 --> 26:15.840
See ya.