summaryrefslogtreecommitdiffstats
path: root/2022/captions/emacsconf-2022-detached--getting-detached-from-emacs--niklas-eklund--answers.vtt
blob: 7d9c79207847fe0705478228cd823ab90897619c (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
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.