WEBVTT
00:00:00.000 --> 00:00:03.600
going to start recording. All right. Thanks, Michael, for
00:00:03.600 --> 00:00:05.040
the great talk. So
00:00:05.040 --> 00:00:09.070
the Q&A is live now. Folks can ask questions on IRC or the
00:00:09.070 --> 00:00:10.440
pad. And then
00:00:10.440 --> 00:00:12.660
at some later point, we'll also open up this PDB room
00:00:12.660 --> 00:00:13.860
itself for people to join
00:00:13.860 --> 00:00:16.310
and ask their questions here if they want. Michael, take it
00:00:16.310 --> 00:00:16.720
away.
00:00:16.720 --> 00:00:21.470
Okay, I will start with the first question of etherpad is
00:00:21.470 --> 00:00:22.600
are you using
00:00:22.600 --> 00:00:28.920
this as it as a replacement of x ex WM? No, not yet. But I
00:00:28.920 --> 00:00:33.040
'm planning to. I'm a
00:00:33.040 --> 00:00:39.700
I use x WM since many years like for my main computing
00:00:39.700 --> 00:00:42.400
environment with Emacs.
00:00:42.400 --> 00:00:47.530
And I would love to have a replacement and Wayland. I'm not
00:00:47.530 --> 00:00:49.120
actually that sure
00:00:49.120 --> 00:00:54.390
if that needed. But I plan on using it. It's not finished.
00:00:54.390 --> 00:00:55.760
So is this testable?
00:00:55.760 --> 00:01:04.660
Yes, it is testable. I have gonna provide you the code. At
00:01:04.660 --> 00:01:05.960
the end of the
00:01:05.960 --> 00:01:10.180
video, there was a link to my site, but there's no site yet
00:01:10.180 --> 00:01:12.160
. I bought this URL a
00:01:12.160 --> 00:01:16.520
year ago, and that's a good reason to put something on
00:01:16.520 --> 00:01:18.040
there. So wait a few
00:01:18.040 --> 00:01:22.250
days and you can download a git repository. At least that's
00:01:22.250 --> 00:01:23.640
the plan. And
00:01:23.640 --> 00:01:26.710
then you can test it. Input handling is still missing, as I
00:01:26.710 --> 00:01:30.560
said. Yes, that makes
00:01:30.560 --> 00:01:36.390
it a bit rough. So the input is only guided by where the
00:01:36.390 --> 00:01:39.560
mouse pointer is. And
00:01:39.560 --> 00:01:43.770
it's missing in the C part in the C server part. But if
00:01:43.770 --> 00:01:45.160
this is in there, I
00:01:45.160 --> 00:01:49.450
think you can use it as a replacement. So it's testable,
00:01:49.450 --> 00:01:50.240
and it's not a
00:01:50.240 --> 00:01:54.140
replacement yet. Have you considered contributing to Emacs
00:01:54.140 --> 00:01:55.080
cores? The next
00:01:55.080 --> 00:02:00.590
question? Yes. Is it a general question? If I would like to
00:02:00.590 --> 00:02:03.680
do that? Yeah, I got
00:02:03.680 --> 00:02:07.560
quite a lot into Emacs core in the last year because I did
00:02:07.560 --> 00:02:08.800
language work with
00:02:08.800 --> 00:02:13.030
Lisp and really nerded out and got to know the core. So I
00:02:13.030 --> 00:02:15.360
like it. Why not? If
00:02:15.360 --> 00:02:18.980
it's a more specific question, if I would like to
00:02:18.980 --> 00:02:20.840
contribute the Wayland
00:02:20.840 --> 00:02:24.810
support to Emacs core, then I'm not that sure if it belongs
00:02:24.810 --> 00:02:27.160
there. Like at first,
00:02:27.160 --> 00:02:29.660
I thought, of course, you have to put it in the core. It's
00:02:29.660 --> 00:02:30.520
C. It has to work
00:02:30.520 --> 00:02:35.120
together. But after I looked into it a little bit more, how
00:02:35.120 --> 00:02:36.280
to do a Wayland
00:02:36.280 --> 00:02:39.270
compositor with Emacs, I found out, okay, there's this Way
00:02:39.270 --> 00:02:40.280
land protocol and
00:02:40.280 --> 00:02:43.970
all the programs that are working together in a Wayland
00:02:43.970 --> 00:02:45.560
desktop, they talk
00:02:45.560 --> 00:02:51.150
in this protocol. And when I got Emacs to talk with the Way
00:02:51.150 --> 00:02:53.320
land protocol, it
00:02:53.320 --> 00:02:57.200
was solved. And that is in the library, because it's an
00:02:57.200 --> 00:02:58.920
asynchronous process,
00:02:58.920 --> 00:03:02.440
like a network connection. And Emacs has an event loop that
00:03:02.440 --> 00:03:05.560
listens to
00:03:06.480 --> 00:03:06.480
00:03:06.480 --> 00:03:09.490
messages on the network. So it's integrated into the Emacs
00:03:09.490 --> 00:03:10.360
core. You
00:03:10.360 --> 00:03:13.870
don't have to do anything more. But where it gets
00:03:13.870 --> 00:03:15.920
interesting, again, is this
00:03:15.920 --> 00:03:21.900
idea I had, maybe we could use it for more in Emacs. Emacs
00:03:21.900 --> 00:03:23.840
is fundamentally
00:03:23.840 --> 00:03:26.740
about drawing buffers to a screen and not fundamentally.
00:03:26.740 --> 00:03:27.720
But the part that's
00:03:27.720 --> 00:03:30.800
not a Lisp machine, the graphical part, it's drawing buff
00:03:30.800 --> 00:03:32.000
ers to a screen and you
00:03:32.000 --> 00:03:36.060
have to composite these buffers somehow. And now we're
00:03:36.060 --> 00:03:38.400
using different desktop
00:03:38.400 --> 00:03:43.640
toolkits like GTK on the Linux. And maybe we don't have to,
00:03:43.640 --> 00:03:45.000
we can just draw
00:03:45.000 --> 00:03:49.980
pixel buffers, like draw into a pixel buffer. Like, I don't
00:03:49.980 --> 00:03:50.880
know, what do we
00:03:50.880 --> 00:03:55.640
use for rendering? I forgot, Cairo or something. And this
00:03:55.640 --> 00:03:56.760
could just write
00:03:56.760 --> 00:03:59.770
into a pixel buffer. So now we arranged, and Emacs is
00:03:59.770 --> 00:04:01.080
already a window manager.
00:04:01.080 --> 00:04:03.970
So it's not that difficult to implement a window manager
00:04:03.970 --> 00:04:05.320
with Emacs because Emacs
00:04:05.320 --> 00:04:11.060
is a window manager, pretty good one, I think. And no, I
00:04:11.060 --> 00:04:13.040
just lost a little bit
00:04:13.040 --> 00:04:16.670
more train of thought. But so far to contributing to the
00:04:16.670 --> 00:04:17.960
core and we could do
00:04:17.960 --> 00:04:20.840
more with it. So next question.
00:04:20.840 --> 00:04:23.960
- One thing, Michael, quickly. Sorry. Yeah, it would be
00:04:23.960 --> 00:04:25.200
great if you could also
00:04:25.200 --> 00:04:27.510
repeat the questions for the stream before you answer them.
00:04:27.510 --> 00:04:28.040
That would be
00:04:28.040 --> 00:04:28.440
awesome.
00:04:28.440 --> 00:04:30.120
- I will do that.
00:04:30.120 --> 00:04:30.920
- Thank you.
00:04:32.600 --> 00:04:32.600
00:04:32.600 --> 00:04:36.260
Question. Is this valent compositor in Emacs? What
00:04:36.260 --> 00:04:39.040
different with XReparent in
00:04:39.040 --> 00:04:45.290
X11? Okay, this is a little bit difficult for me to
00:04:45.290 --> 00:04:48.520
understand, but I answered
00:04:48.520 --> 00:04:53.550
anyway. So first, is this a valent compositor in Emacs? I
00:04:53.550 --> 00:04:54.840
would say no,
00:04:54.840 --> 00:04:58.870
because the Emacs doesn't do the valent compositoring. I
00:04:58.870 --> 00:05:00.440
first planned to do it
00:05:00.440 --> 00:05:03.130
like this, but it doesn't work out like this because you
00:05:03.130 --> 00:05:06.120
have to handle file
00:05:06.120 --> 00:05:10.120
descriptors and Emacs can't handle file descriptors except
00:05:10.120 --> 00:05:11.480
you go down to the C
00:05:11.480 --> 00:05:19.930
part. So no, it's not. It's a C, a WL roots valent compos
00:05:19.930 --> 00:05:22.840
itor that talks to
00:05:22.840 --> 00:05:29.290
Emacs and Emacs is, it's just like a helper compositor. Em
00:05:29.290 --> 00:05:31.160
acs says where to
00:05:31.160 --> 00:05:34.380
put the windows. It's the window manager. And in the future
00:05:34.380 --> 00:05:35.360
, where to put the
00:05:35.360 --> 00:05:40.170
inputs so that you can insert Emacs into the input stream
00:05:40.170 --> 00:05:43.320
like XWM does it. Okay,
00:05:43.320 --> 00:05:49.070
then what different with XReparent in X11? I don't actually
00:05:49.070 --> 00:05:51.000
know what XReparent
00:05:51.000 --> 00:05:55.150
is, so I'm sorry. I have to skip this one. How would
00:05:55.150 --> 00:05:57.000
multiple monitors be
00:05:57.000 --> 00:05:59.990
handled? Separate frames? Yes, separate frames. This is
00:05:59.990 --> 00:06:01.160
already testable. It's
00:06:01.160 --> 00:06:08.540
implemented. As soon as a new monitor crops up, the Emacs
00:06:08.540 --> 00:06:10.320
is, the valent
00:06:10.320 --> 00:06:15.490
protocol informs about a new output event and Emacs then
00:06:15.490 --> 00:06:17.000
pops up a new frame
00:06:17.000 --> 00:06:22.240
on this output. And depending on how usable you want to
00:06:22.240 --> 00:06:24.760
have it, you can just,
00:06:24.760 --> 00:06:27.160
there could be a menu like where do you want the output? Do
00:06:27.160 --> 00:06:27.840
you want to have a
00:06:27.840 --> 00:06:30.230
screen on it or something like that? And then you have
00:06:30.230 --> 00:06:31.480
output handling. Output
00:06:31.480 --> 00:06:35.100
handling is already working. So separate frames, one per
00:06:35.100 --> 00:06:37.480
output because that's
00:06:37.480 --> 00:06:41.010
the Emacs analog. You have windows, you have frames, frames
00:06:41.010 --> 00:06:42.760
are like monitors.
00:06:42.760 --> 00:06:45.800
And the special thing about valent outputs is they don't
00:06:45.800 --> 00:06:46.600
have to be a whole
00:06:46.600 --> 00:06:49.980
monitor or hardware device. They can also be like a normal
00:06:49.980 --> 00:06:52.840
frame. Next question
00:06:52.840 --> 00:06:57.440
is, could you make it so you can restart Emacs without
00:06:57.440 --> 00:06:59.400
logging out or switch to
00:06:59.400 --> 00:07:02.640
non-Emacs buffer while Emacs is blocking? These are the
00:07:02.640 --> 00:07:05.080
biggest issues with XWM.
00:07:05.080 --> 00:07:13.240
While Emacs is blocking. Okay, I have to think about this a
00:07:13.240 --> 00:07:14.760
little bit
00:07:16.120 --> 00:07:19.270
because right now I have a problem with restarting and the
00:07:19.270 --> 00:07:20.600
code I wrote. Emacs
00:07:20.600 --> 00:07:25.340
starts the valent server and then starts to talk to it, the
00:07:25.340 --> 00:07:28.520
server to Emacs. And
00:07:28.520 --> 00:07:33.070
as soon as the server terminates, Emacs terminates. Because
00:07:33.070 --> 00:07:34.680
GTK has this feature
00:07:34.680 --> 00:07:38.550
and it's a bug since several years and they know it, but
00:07:38.550 --> 00:07:39.880
apparently it's a
00:07:39.880 --> 00:07:44.830
feature, not a bug. So as soon as a valent GTK window
00:07:44.830 --> 00:07:47.000
terminates, it terminates
00:07:47.000 --> 00:07:51.420
its process. That means if there's an Emacs frame on valent
00:07:51.420 --> 00:07:52.440
and the frame is
00:07:52.440 --> 00:07:57.610
powered by GTK as Emacs currently does it, valent termin
00:07:57.610 --> 00:07:59.560
ates the frame, Emacs
00:07:59.560 --> 00:08:02.870
gets terminated, whole thing is terminated. Well, normally
00:08:02.870 --> 00:08:03.480
you would like
00:08:03.480 --> 00:08:06.500
something that like Emacs terminal frame, and then you pop
00:08:06.500 --> 00:08:07.640
open valent buffer
00:08:07.640 --> 00:08:10.160
or something like that. And it's just a long running Emacs
00:08:10.160 --> 00:08:11.640
session, but that's
00:08:11.640 --> 00:08:16.670
a blocker right now and it's GTK's fault. But we already
00:08:16.670 --> 00:08:18.040
know the other
00:08:18.040 --> 00:08:22.220
bug we have since years. And so I don't think this one is
00:08:22.220 --> 00:08:23.640
resolved either.
00:08:23.640 --> 00:08:29.040
So what does mean or switch to non-Emacs buffers while Em
00:08:29.040 --> 00:08:31.000
acs is blocking? No,
00:08:31.000 --> 00:08:35.090
you can't. Okay. Now you can't do this because Emacs does
00:08:35.090 --> 00:08:36.200
the window managing
00:08:36.200 --> 00:08:43.700
as in EXWM. So there's a new window or you want to switch a
00:08:43.700 --> 00:08:45.960
window. So it has
00:08:45.960 --> 00:08:50.640
to go through Emacs. Emacs gets a request for new window or
00:08:50.640 --> 00:08:52.280
Emacs just says layout
00:08:52.280 --> 00:08:55.820
this window at this point. And if Emacs as it's single
00:08:55.820 --> 00:08:58.200
threaded is blocked, it
00:08:58.200 --> 00:09:05.830
can't issue this layout request. So yeah, that's not going
00:09:05.830 --> 00:09:09.320
to work out as long
00:09:09.320 --> 00:09:17.190
as Emacs is just single threaded. Next question. Did this
00:09:17.190 --> 00:09:19.400
project can implement
00:09:19.400 --> 00:09:23.680
mirror of buffer for Emacs different window? Okay. I think
00:09:23.680 --> 00:09:25.320
I got this question.
00:09:27.320 --> 00:09:31.810
Can you, okay. In Emacs normally you know how buffers work.
00:09:31.810 --> 00:09:32.760
Like you have one
00:09:32.760 --> 00:09:35.420
buffer, you split it, you have two buffers, but it's the
00:09:35.420 --> 00:09:37.000
same buffer. Then you can
00:09:37.000 --> 00:09:39.320
take one of the buffers and look at another place in this
00:09:39.320 --> 00:09:42.360
buffer. You can't do
00:09:42.360 --> 00:09:45.930
this with Emacs buffers, but you can't do it like an EXWM.
00:09:45.930 --> 00:09:47.080
You can't do it with
00:09:47.080 --> 00:09:50.980
the X windows because there's only one view on the X
00:09:50.980 --> 00:09:54.440
windows. So now the special
00:09:54.440 --> 00:09:57.790
thing with Valent, you can have multiple views on the same
00:09:57.790 --> 00:10:00.040
window. And when I got
00:10:00.040 --> 00:10:03.210
to implement this idea, I was, yeah, of course I'm going to
00:10:03.210 --> 00:10:04.440
do multiple views,
00:10:04.440 --> 00:10:09.710
same window as Emacs does it. And I had it implemented. And
00:10:09.710 --> 00:10:11.560
then I found out, no,
00:10:11.560 --> 00:10:16.660
this is not going to work. Because a window has always one
00:10:16.660 --> 00:10:18.920
size. Like you can't,
00:10:18.920 --> 00:10:23.000
if you have a video open, you can't just tell it, make it
00:10:23.000 --> 00:10:24.680
this size. Or if you have
00:10:24.680 --> 00:10:29.080
a web browser open and you can't have different sizes. So
00:10:29.080 --> 00:10:32.360
it's in principle, it's
00:10:32.360 --> 00:10:37.910
comfortable with the Emacs model. Like the normal desktop
00:10:37.910 --> 00:10:39.640
model doesn't work with Emacs. So
00:10:39.640 --> 00:10:44.200
no, this still doesn't work. You can do a hack. I tried it.
00:10:44.200 --> 00:10:45.320
You have like one big
00:10:45.320 --> 00:10:48.750
window that you have other windows and you scale them or
00:10:48.750 --> 00:10:50.600
you crop them, but this isn't
00:10:50.600 --> 00:10:54.890
well supported in WL roots. And also it doesn't make a lot
00:10:54.890 --> 00:10:57.720
of sense actually. So I scrapped it
00:10:57.720 --> 00:11:02.030
and there's just one view. Okay. So just one view because
00:11:02.030 --> 00:11:04.280
it doesn't make a lot of sense to have
00:11:04.280 --> 00:11:08.120
multiple views. How does this next question, how does the
00:11:08.120 --> 00:11:10.840
single threaded, threaded affects
00:11:10.840 --> 00:11:16.470
the project? Yeah. And so far as it does affect any Emacs
00:11:16.470 --> 00:11:19.640
package, like it's not a special
00:11:19.640 --> 00:11:25.400
problem, not a, not a actual problem. Like the only, only,
00:11:25.400 --> 00:11:26.480
um, um,
00:11:26.480 --> 00:11:32.850
there's just one thing where Emacs could block, uh, the
00:11:32.850 --> 00:11:35.720
other windows. It's when the other window
00:11:35.720 --> 00:11:39.730
requests a layout, like there's a new program that opened a
00:11:39.730 --> 00:11:42.760
window or another window opened
00:11:42.760 --> 00:11:46.840
and Emacs is blocking and can't service this new surface
00:11:46.840 --> 00:11:49.400
request. So you won't see anything,
00:11:49.400 --> 00:11:53.620
but except from that, um, if you see the window Emacs hangs
00:11:53.620 --> 00:11:57.320
like with the EXWVM, you just can use
00:11:57.320 --> 00:12:00.790
the other program because it's not coupled to Emacs in any
00:12:00.790 --> 00:12:02.120
significant way.
00:12:03.720 --> 00:12:08.190
Um, and the good thing is, and that's the short side remark
00:12:08.190 --> 00:12:11.240
. If you want to go further than our
00:12:11.240 --> 00:12:14.000
single threaded thing, it's like, I think we, we have a
00:12:14.000 --> 00:12:16.200
talk somewhere in this conference, like,
00:12:16.200 --> 00:12:21.420
um, how Emacs was always async and is it, is async and Em
00:12:21.420 --> 00:12:24.200
acs is async. Well, we have async
00:12:24.200 --> 00:12:27.670
processes. We have callbacks, we have network processes we
00:12:27.670 --> 00:12:29.800
can use asynchronously. And I think
00:12:29.800 --> 00:12:33.820
that's the way forward for Emacs to don't be blocking, like
00:12:33.820 --> 00:12:35.800
have worker threads, something
00:12:35.800 --> 00:12:40.140
like this and have a main thing because it's one big muddle
00:12:40.140 --> 00:12:43.160
of muddle of code. I don't think you
00:12:43.160 --> 00:12:49.280
can just separate it. So, but we could lean more into these
00:12:49.280 --> 00:12:53.320
helpers and workers like Node.js does
00:12:53.320 --> 00:12:57.950
it or something like that. So next question is this
00:12:57.950 --> 00:13:01.800
technology. I have a short matter question.
00:13:01.800 --> 00:13:08.200
Do I have to stop or can I answer all the questions? Um,
00:13:08.200 --> 00:13:09.880
yeah, I think we can go on for now.
00:13:09.880 --> 00:13:13.420
And, um, the BBB room is also open for anyone who does want
00:13:13.420 --> 00:13:15.720
to join here to ask questions directly,
00:13:15.720 --> 00:13:18.420
um, in case the stream moves on. But I think this is our
00:13:18.420 --> 00:13:20.280
last talk on the Dev track before the launch
00:13:20.280 --> 00:13:22.850
break. So yeah, you should be good. Ah, nice. I don't need
00:13:22.850 --> 00:13:24.520
a lunch break because, uh, uh,
00:13:24.520 --> 00:13:32.110
in Europe it's already like the next meal. Right. So, um,
00:13:32.110 --> 00:13:34.760
next question is this technology
00:13:34.760 --> 00:13:38.840
need right? Valence server. Can it works with GNOME 3?
00:13:38.840 --> 00:13:42.760
Actually, yes, it needs to write a
00:13:42.760 --> 00:13:47.490
valence server because valence needs a valence server. And,
00:13:47.490 --> 00:13:49.320
uh, just for you, what does the
00:13:49.320 --> 00:13:53.900
server actually do? The server does, um, for example, it is
00:13:53.900 --> 00:13:55.880
the compositor. The valence
00:13:55.880 --> 00:13:58.680
compositor is part of the valence compositor. It's like
00:13:58.680 --> 00:14:00.360
difficult naming they had there.
00:14:00.360 --> 00:14:04.320
And it does a merging of, of windows. You have, um, you
00:14:04.320 --> 00:14:06.760
have an application and it draws a window.
00:14:06.760 --> 00:14:09.730
So you give it a pixel buffer, the application draws in
00:14:09.730 --> 00:14:11.560
this pixel buffer, and then you put it
00:14:11.560 --> 00:14:16.310
on the screen and compositor this other surfaces that are
00:14:16.310 --> 00:14:19.560
on the screen. And, um, you have to look
00:14:19.560 --> 00:14:22.320
into the frame rate you want to have and stuff like that.
00:14:22.320 --> 00:14:24.360
So it's really low level stuff. It's,
00:14:24.360 --> 00:14:28.020
it's, um, that's the thing the valence compositor does. And
00:14:28.020 --> 00:14:30.200
it does input handling like lip input,
00:14:30.200 --> 00:14:33.760
and then it receives something and routes it to this
00:14:33.760 --> 00:14:37.320
surface of that surface, or I think shell
00:14:37.320 --> 00:14:41.340
it's called. It's a shell that reserves the input. Okay.
00:14:41.340 --> 00:14:44.760
Can it work with GNOME 3? Yes,
00:14:44.760 --> 00:14:47.930
maybe. I don't know how open they are and if you can
00:14:47.930 --> 00:14:50.600
integrate it, but I don't think that's,
00:14:50.600 --> 00:14:55.520
that's a good direction because what do you want to build?
00:14:55.520 --> 00:15:00.040
So, ah, just one thing since Emacs can
00:15:00.040 --> 00:15:04.130
talk valence and is a normal valence client with the
00:15:04.130 --> 00:15:07.880
library I wrote, it can take, can talk to any
00:15:07.880 --> 00:15:13.520
other valence program and maybe you can do something useful
00:15:13.520 --> 00:15:16.520
with GNOME 3 and Emacs as a
00:15:16.520 --> 00:15:19.500
valence client. Like you can automate parts of your desktop
00:15:19.500 --> 00:15:21.720
or something like that. Um, yeah,
00:15:21.720 --> 00:15:25.850
that would be a possibility. Good. I'm going now to the
00:15:25.850 --> 00:15:28.200
next question that is, could there be an
00:15:28.200 --> 00:15:31.940
Emacs valence server and just connect with Emacs client?
00:15:31.940 --> 00:15:36.600
Cool. I named my thing Emacs valence
00:15:36.600 --> 00:15:42.050
server. So there is already an Emacs valence server. Um,
00:15:42.050 --> 00:15:44.600
connect with Emacs client.
00:15:44.600 --> 00:15:50.600
I don't actually get the question, but I think, um, yes, of
00:15:50.600 --> 00:15:53.080
course you have an Emacs running.
00:15:53.080 --> 00:15:56.070
It doesn't have to be an Emacs valence server because Emacs
00:15:56.070 --> 00:15:56.920
is multi-display
00:15:56.920 --> 00:16:01.090
and then you can just pop open the windows in valence or
00:16:01.090 --> 00:16:04.360
something like this. Next question is
00:16:04.360 --> 00:16:07.650
when you share your code, could you provide the equivalent
00:16:07.650 --> 00:16:10.040
of an X session script for those who
00:16:10.040 --> 00:16:17.920
are on XWM and want to test? Yes, I can, because it's my
00:16:17.920 --> 00:16:21.720
goal is to have it run like this for
00:16:21.720 --> 00:16:24.660
myself. But when I share the code in the coming days, as I
00:16:24.660 --> 00:16:29.640
'm planning, no, you won't run it like
00:16:29.640 --> 00:16:33.910
this because it's not that polished yet. So a startup is a
00:16:33.910 --> 00:16:36.360
little bit more involved and I
00:16:36.360 --> 00:16:41.030
haven't researched all the ways you can make it polished,
00:16:41.030 --> 00:16:44.600
but it's on the roadmap. So stay tuned.
00:16:46.520 --> 00:16:51.220
The next question is, I have a demo to show this Emacs val
00:16:51.220 --> 00:16:52.520
ence compositor,
00:16:52.520 --> 00:16:56.900
even if buggy now, just curious. Yes, there is a demo. Like
00:16:56.900 --> 00:16:59.480
you just watched one in the video. It
00:16:59.480 --> 00:17:06.370
was the compositor running. It did the compositing of the
00:17:06.370 --> 00:17:11.080
video I made. And the other demo is the
00:17:11.080 --> 00:17:16.980
code I'm planning to release. The code right now is working
00:17:16.980 --> 00:17:21.960
, but there's some documentation also,
00:17:21.960 --> 00:17:26.510
but it's not finished. So have fun digging in there, but
00:17:26.510 --> 00:17:29.400
don't expect anything like hyper
00:17:29.400 --> 00:17:33.690
polished or something like this. More, yeah, I'm looking
00:17:33.690 --> 00:17:36.680
for feedback and ideas and where to take
00:17:36.680 --> 00:17:42.260
this thing. Now we're going to get to buffer mirroring. So
00:17:42.260 --> 00:17:44.760
next question is, so the current
00:17:44.760 --> 00:17:47.950
limitation is that buffer mirroring doesn't respect
00:17:47.950 --> 00:17:50.360
different widths or heights. Yeah,
00:17:50.360 --> 00:17:53.530
the limitation is fundamentally if you have a normal
00:17:53.530 --> 00:17:55.800
desktop window, look at your browser
00:17:55.800 --> 00:17:59.980
or your video player, just watching me, you are just
00:17:59.980 --> 00:18:04.600
watching me. It just has one size. You can't
00:18:04.600 --> 00:18:08.570
say, please make yourself this size and this size and show
00:18:08.570 --> 00:18:12.040
me two different parts of your site or
00:18:12.040 --> 00:18:17.520
that doesn't work. It's not thought like this. So you can
00:18:17.520 --> 00:18:20.680
hack something up that you have like
00:18:20.680 --> 00:18:24.300
a big window and then you show a little crop part of it and
00:18:24.300 --> 00:18:26.760
another buffer. This does actually work,
00:18:27.560 --> 00:18:32.940
but just a little site or like if you want to do something
00:18:32.940 --> 00:18:38.680
like this, be prepared. WL roots doesn't,
00:18:38.680 --> 00:18:43.740
okay. So a Wayland server or compositor has to do its own
00:18:43.740 --> 00:18:47.880
compositing. That means it has to
00:18:47.880 --> 00:18:51.590
composite the different buffers or pixel buffer it has in
00:18:51.590 --> 00:18:53.880
one pixel buffer and put it on the output.
00:18:55.000 --> 00:18:59.600
That means you have to do that yourself. And there's a
00:18:59.600 --> 00:19:01.960
helper to do this in WL roots.
00:19:01.960 --> 00:19:07.410
This is WLR scene as it's called. And it does this for you.
00:19:07.410 --> 00:19:09.720
You build a scene tree and does
00:19:09.720 --> 00:19:14.510
damage tracking so it doesn't repaint everything. It saves
00:19:14.510 --> 00:19:16.920
battery and it's a lot of work to do this
00:19:16.920 --> 00:19:21.710
and it's ready there. But what is missing in this helper is
00:19:21.710 --> 00:19:24.920
cropping and resizing. So right now you
00:19:24.920 --> 00:19:28.700
can't crop and you can't resize. And I would say this is
00:19:28.700 --> 00:19:31.240
the main blocker for using the thing I
00:19:31.240 --> 00:19:38.100
built, Wayland compositor is you can't crop windows. And if
00:19:38.100 --> 00:19:42.920
you, maybe you use MP4 like the
00:19:42.920 --> 00:19:48.310
video player, it doesn't respect what you tell it, what the
00:19:48.310 --> 00:19:51.480
size it should get. It just, it keeps its
00:19:51.480 --> 00:19:55.400
aspect ratio and then just respects and either width or
00:19:55.400 --> 00:19:58.280
height, but not both if they don't fit.
00:19:58.280 --> 00:20:01.790
So you want to fit it in a buffer and then it's stay, it's
00:20:01.790 --> 00:20:04.360
overflows the buffer a little bit. You
00:20:04.360 --> 00:20:09.200
can see it in the talk video. In my talk, I posted like the
00:20:09.200 --> 00:20:11.720
little camera picture of me is not always
00:20:11.720 --> 00:20:15.550
there where it should be. It's over the mode line or
00:20:15.550 --> 00:20:18.680
something like that. And yeah, there needs to
00:20:18.680 --> 00:20:25.180
be some cropping. XWVM does cropping. It crops. You can try
00:20:25.180 --> 00:20:28.920
it out. If someone of you is a XWM
00:20:28.920 --> 00:20:39.560
user, he can do a full screen video MP4 video, and then
00:20:39.560 --> 00:20:42.200
just split right. And then you'll see
00:20:42.200 --> 00:20:46.990
just half the video screen because it's no cropped, but the
00:20:46.990 --> 00:20:49.320
video player in the background
00:20:49.320 --> 00:20:55.480
still sends the full screen. Okay. So much for this topic.
00:20:55.480 --> 00:20:59.420
Ah, okay. And if you want to do cropping, you have to do
00:20:59.420 --> 00:21:03.720
your own compositor. I asked the real W
00:21:05.080 --> 00:21:09.870
WL roots. Sorry. That's this W is complicated for me. I
00:21:09.870 --> 00:21:16.120
asked the WL roots developers on their IRC
00:21:16.120 --> 00:21:19.450
channel and they told me, yes, we wanted to have this. We
00:21:19.450 --> 00:21:21.400
have an issue open, but it's not
00:21:21.400 --> 00:21:24.870
implemented and you have to do it yourself. And yes,
00:21:24.870 --> 00:21:27.320
whoever wants us has to do it himself. And
00:21:27.320 --> 00:21:32.180
that's a lot of work in C. Okay. I'll jump in quickly at
00:21:32.180 --> 00:21:33.800
one thing. Yeah. I think we were about
00:21:33.800 --> 00:21:36.040
like two minutes break, sorry, two minutes away from our
00:21:36.040 --> 00:21:38.840
lunch break. At which point I think the
00:21:38.840 --> 00:21:42.160
stream will be moving on or will be stopped, but this BQB
00:21:42.160 --> 00:21:44.600
room will be open. So yeah, Michael and
00:21:44.600 --> 00:21:47.250
anyone else who is participating in the Q&A, you're more
00:21:47.250 --> 00:21:49.160
than welcome to stay here and continue the
00:21:49.160 --> 00:21:55.160
question and answer. Okay. Thank you for this announcement.
00:21:55.160 --> 00:21:59.960
Yeah. I would like to keep answering
00:21:59.960 --> 00:22:05.570
questions and maybe yeah, until there's no more interest or
00:22:05.570 --> 00:22:08.200
I am hungry too, but I don't need a
00:22:08.200 --> 00:22:12.600
lunch as I already. Yep. Okay. Sounds great. Yep. So yeah,
00:22:12.600 --> 00:22:14.840
the stream will probably be cut off in
00:22:14.840 --> 00:22:17.940
about a minute or so, but yeah, this room will be open and
00:22:17.940 --> 00:22:20.040
you and others will be able to stay here
00:22:20.040 --> 00:22:25.160
and keep asking and answering questions. Okay. Thanks.
00:22:25.160 --> 00:22:29.720
Thank you. Then let's go on to the next
00:22:29.720 --> 00:22:48.790
question. I just scrolled. I forgot my place. Okay. Could
00:22:48.790 --> 00:22:51.000
you use some of the packages with
00:22:51.000 --> 00:22:54.920
other Wayland compositors? Probably not all of it's way KDE
00:22:54.920 --> 00:22:57.160
, Rivergnome. Yes, you can. And thank
00:22:57.160 --> 00:23:01.680
you for this idea because I already, I didn't think of this
00:23:01.680 --> 00:23:04.440
before. You can use it because you
00:23:04.440 --> 00:23:07.620
can talk to them. Like you can talk to Wayland protocols.
00:23:07.620 --> 00:23:09.560
You can have a look at them. There's
00:23:09.560 --> 00:23:14.830
like the core protocol of Wayland is in the core repository
00:23:14.830 --> 00:23:18.120
of the Wayland project. And there's a
00:23:18.120 --> 00:23:21.680
Wayland protocols repository. They have like three tier
00:23:21.680 --> 00:23:23.720
staging, experimental and stable,
00:23:23.720 --> 00:23:26.900
almost nothing in Wayland is stable. So be prepared for
00:23:26.900 --> 00:23:28.920
some changes in the future, I think.
00:23:28.920 --> 00:23:35.700
And you can talk to these protocols. They are not that
00:23:35.700 --> 00:23:39.800
difficult, but some things are already a bit
00:23:39.800 --> 00:23:43.370
too complicated. Like you have to take output and then to
00:23:43.370 --> 00:23:45.640
get the actual width or something like
00:23:45.640 --> 00:23:49.630
this, you have to request another output. And this one
00:23:49.630 --> 00:23:52.600
talks to you and the other output says, okay,
00:23:52.600 --> 00:23:55.050
I'm done or something like this. Some things are a little
00:23:55.050 --> 00:23:58.680
bit difficult, but it's quite readable
00:23:58.680 --> 00:24:03.520
and understandable and you can do scripting Sway, but I don
00:24:03.520 --> 00:24:06.120
't have a lot of experience there because
00:24:06.120 --> 00:24:11.930
like I'm an XWM user. I do it in Emacs. I'm staying on X. I
00:24:11.930 --> 00:24:14.520
had Sway several years ago,
00:24:14.520 --> 00:24:18.110
but only a short time. So I'm not that knowledgeable. The
00:24:18.110 --> 00:24:20.040
next question is,
00:24:20.760 --> 00:24:26.170
will Wayland support reach feature parity with XWM in the
00:24:26.170 --> 00:24:29.560
future? Will there be other trade-offs?
00:24:29.560 --> 00:24:35.830
No, it won't. Okay. But don't think, it's not something
00:24:35.830 --> 00:24:38.760
usable because I don't think all the
00:24:38.760 --> 00:24:45.530
features in the EXWM is needed. I want to work spaces as I
00:24:45.530 --> 00:24:49.320
said in the talk, because yeah,
00:24:49.320 --> 00:24:53.460
Emacs does work spaces and I won't do this, but I will do
00:24:53.460 --> 00:24:58.200
everything. Like what's my plan with
00:24:58.200 --> 00:25:01.690
this thing? It's like the two use cases I already alluded
00:25:01.690 --> 00:25:06.280
to in the video. The first is you have a
00:25:06.280 --> 00:25:11.030
Wayland surface and you show it inside an Emacs buffer or
00:25:11.030 --> 00:25:13.160
an Emacs window. So you have a kind of
00:25:13.160 --> 00:25:22.510
Wayland buffer, I'm calling it. That's the thing EXWM does.
00:25:22.510 --> 00:25:26.600
And I think, yeah, it should reach
00:25:26.600 --> 00:25:30.710
feature parity with it. It also has output management and
00:25:30.710 --> 00:25:32.600
like the input handling,
00:25:32.600 --> 00:25:37.700
there's like the simulation keys and I don't know what else
00:25:37.700 --> 00:25:41.080
, but actually I don't have a solution
00:25:41.080 --> 00:25:46.060
yet for the input handling. It's a thing I haven't looked
00:25:46.060 --> 00:25:49.480
that much into. Will there be other
00:25:49.480 --> 00:25:53.660
trade-offs? Yeah, most certainly there are always trade-
00:25:53.660 --> 00:25:56.200
offs, but I can't tell you which.
00:25:56.200 --> 00:26:00.920
So the next question is, what is the biggest difference
00:26:00.920 --> 00:26:01.880
between X,
00:26:01.880 --> 00:26:07.000
Org and Wayland that you have found? Okay, what's the
00:26:07.000 --> 00:26:10.360
biggest difference?
00:26:10.360 --> 00:26:18.970
Don't know actually, don't know. First of all, I'm not that
00:26:18.970 --> 00:26:23.320
knowledgeable in X, Org. I used it,
00:26:23.320 --> 00:26:28.150
but I have no more programs in X Window Manager. I haven't
00:26:28.150 --> 00:26:30.520
looked a lot into it, except
00:26:31.400 --> 00:26:37.380
WEM, I looked into the code, into Elisp code and how it
00:26:37.380 --> 00:26:39.880
does the communication and
00:26:39.880 --> 00:26:46.750
took inspiration of course. Yeah, big difference is you don
00:26:46.750 --> 00:26:50.120
't have one monolithic server. Like you
00:26:50.120 --> 00:26:54.390
have one X, Org server and in Wayland you have lots of
00:26:54.390 --> 00:26:57.800
servers like GNOME has one, KDE has one,
00:26:58.760 --> 00:27:02.510
then WL roots is another approach, Swae has an
00:27:02.510 --> 00:27:05.480
implementation in WL roots and so on.
00:27:05.480 --> 00:27:10.350
So now it's the last question I find in my path is, did you
00:27:10.350 --> 00:27:13.880
know EAF? Yes, I know. Of course,
00:27:13.880 --> 00:27:17.000
like I think we have a talk. We have a talk. We had talks
00:27:17.000 --> 00:27:21.400
and I never used it. I'm sorry.
00:27:22.440 --> 00:27:29.400
Maybe it's interesting. It's Python. I don't do a lot of
00:27:29.400 --> 00:27:31.640
Python and
00:27:31.640 --> 00:27:37.220
similar use case. It's like, I think it's embedded X
00:27:37.220 --> 00:27:40.200
widgets. Please correct me if I'm wrong.
00:27:40.200 --> 00:27:47.450
Yeah, that's all I can say to this topic. But I think like
00:27:47.450 --> 00:27:49.800
any application framework,
00:27:49.800 --> 00:27:53.920
you can want to do an Emacs or stuff like that will mesh
00:27:53.920 --> 00:27:57.240
really good with Emacs compositor that
00:27:57.240 --> 00:28:02.650
is integrated or like almost integrated in Emacs because
00:28:02.650 --> 00:28:05.640
now you can use this to do your application
00:28:05.640 --> 00:28:10.070
framework and paint the windows in Emacs. And I think maybe
00:28:10.070 --> 00:28:12.440
we can come back to the reparenting
00:28:12.440 --> 00:28:18.450
X thing, which I don't really understand. So I don't know
00:28:18.450 --> 00:28:21.560
exactly how X does the X widgets, like
00:28:21.560 --> 00:28:28.190
no idea. But I think we can do something similar with Way
00:28:28.190 --> 00:28:31.960
land. Like we can just embed the little
00:28:31.960 --> 00:28:36.710
Wayland surfaces in an Emacs buffer. And that's a thing I
00:28:36.710 --> 00:28:40.440
wanted to get a discussion started.
00:28:40.440 --> 00:28:45.950
Someone, yeah, maybe someone has an idea. Maybe someone is
00:28:45.950 --> 00:28:49.000
already deep down in Emacs internals
00:28:49.000 --> 00:28:54.620
and knows how these displays stuff works like image display
00:28:54.620 --> 00:28:57.880
, X widget display, and so on.
00:28:57.880 --> 00:29:03.290
And maybe this person or someone else has an idea how we
00:29:03.290 --> 00:29:05.640
could do the Wayland surfaces.
00:29:05.640 --> 00:29:09.280
Right now it's just Emacs receives a request for new
00:29:09.280 --> 00:29:13.160
surface. Okay. You open a new program.
00:29:13.160 --> 00:29:16.430
The program says to the Wayland server, "Hey, I'm here. I
00:29:16.430 --> 00:29:19.480
want to have surface." Wayland server
00:29:19.480 --> 00:29:24.750
gives it the surface and says to Emacs, "Hey, here's a new
00:29:24.750 --> 00:29:27.880
surface. You can lay it out." And
00:29:27.880 --> 00:29:31.080
Emacs then can lay it out or not, however it likes.
00:29:31.080 --> 00:29:33.480
Normally the default path I choose is
00:29:33.480 --> 00:29:38.490
Emacs bundles, the surface with a buffer. And if the buffer
00:29:38.490 --> 00:29:40.600
is shown, it shows the surface.
00:29:40.600 --> 00:29:43.690
And otherwise it's just hidden. But you can do whatever you
00:29:43.690 --> 00:29:45.800
want with the surface. You just
00:29:45.800 --> 00:29:49.050
have to say, please put it at this coordinate and this
00:29:49.050 --> 00:29:52.280
width and this height. So you can put it in
00:29:52.280 --> 00:29:54.980
a buffer and you can scroll it in a buffer. But this
00:29:54.980 --> 00:29:57.560
integration, how to put something in a buffer
00:29:57.560 --> 00:30:00.060
and scroll it there. I don't know how to do it. And I don't
00:30:00.060 --> 00:30:02.920
know how to do it. It should be like
00:30:02.920 --> 00:30:06.070
a good solution. I don't know how to do it. Maybe someone
00:30:06.070 --> 00:30:10.040
of you has an idea. I'm finished with the
00:30:10.040 --> 00:30:17.190
questions of the path. I haven't had a look in IRC because
00:30:17.190 --> 00:30:20.600
yes, I was busy talking.
00:30:20.600 --> 00:30:27.910
I can either like browse through the IRC if you want, or
00:30:27.910 --> 00:30:31.480
maybe someone wants to say something or
00:30:31.480 --> 00:30:36.410
have a look. Ah, thank you. I already answered the IRC
00:30:36.410 --> 00:30:39.880
questions. So yes, I'm finished.
00:30:39.880 --> 00:30:47.720
I still see some people in the room. Yeah. Maybe someone,
00:30:47.720 --> 00:30:49.880
if you have an idea or wants to use it.
00:30:49.880 --> 00:30:58.330
I don't know how fast I will have it in a usable state. It
00:30:58.330 --> 00:30:58.840
's like,
00:31:01.080 --> 00:31:05.200
at first I just wanted to do this presentation and show to
00:31:05.200 --> 00:31:09.400
you the possibility. I already read
00:31:09.400 --> 00:31:13.400
in the internet some places like Emacs, Devel, Mailindus
00:31:13.400 --> 00:31:16.120
that was one time and other places that
00:31:16.120 --> 00:31:20.080
other people's had the same, other person had the same
00:31:20.080 --> 00:31:25.800
ideas. But I was thinking just to lay out
00:31:25.800 --> 00:31:29.740
the general idea to you. And then I thought, okay, do an
00:31:29.740 --> 00:31:32.200
experiment, show if it works. And the
00:31:32.200 --> 00:31:35.870
experiments spun a little bit. It worked. And so I got
00:31:35.870 --> 00:31:40.520
further and now I have an almost usable thing,
00:31:40.520 --> 00:31:46.990
but I already spent like a month with it. So we'll take
00:31:46.990 --> 00:31:49.640
some more time to finish.
00:31:52.840 --> 00:31:59.040
Yeah. Thanks that you think, Gary, that you think it's, you
00:31:59.040 --> 00:32:03.800
are happy to test it. Thank you.
00:32:03.800 --> 00:32:08.870
I would like to have it like a little bit more flexible
00:32:08.870 --> 00:32:11.240
than the X solutions, because
00:32:11.240 --> 00:32:16.880
as I told you can have it nested, like you have a normal Em
00:32:16.880 --> 00:32:20.760
acs and you can just do the embedding
00:32:20.760 --> 00:32:24.710
and the embedded surfaces. And so in a normal Emacs and you
00:32:24.710 --> 00:32:27.400
don't have to give Emacs the whole
00:32:27.400 --> 00:32:35.080
desktop. So you don't have to do XWM. You can just have a
00:32:35.080 --> 00:32:39.080
normal Emacs window and have all the goodies
00:32:39.080 --> 00:32:45.770
and features there. Okay. Again, the code will be available
00:32:45.770 --> 00:32:49.080
on my site. I can post you the link,
00:32:49.080 --> 00:32:54.330
but there's nothing there yet. Oh, wait a few days. I was
00:32:54.330 --> 00:32:57.480
thinking of doing it this weekend,
00:32:57.480 --> 00:33:03.190
but it's EmacsConf and I want to listen to your ideas and
00:33:03.190 --> 00:33:06.360
participate and don't do coding instead.
00:33:06.360 --> 00:33:15.080
This is the link. I could put it on another code forge, but
00:33:15.080 --> 00:33:18.120
I want to do something
00:33:19.880 --> 00:33:19.880
00:33:19.880 --> 00:33:26.340
myself instead. I have a landing page. If I put it in my
00:33:26.340 --> 00:33:29.320
browser, it's just,
00:33:29.320 --> 00:33:35.840
yeah, no connection possible. It's not configured. It's
00:33:35.840 --> 00:33:39.080
just bought, wait a few days.
00:33:42.120 --> 00:33:46.520
Okay. Short question for the room. Does anyone know someone
00:33:46.520 --> 00:33:48.280
else working on stuff like this?
00:33:48.280 --> 00:34:05.250
Because if, please let them know so we can team up and don
00:34:05.250 --> 00:34:06.840
't do it twice.
00:34:11.800 --> 00:34:14.440
I had a lot of fun with the Emacs part of the code. I like
00:34:14.440 --> 00:34:17.640
coding in Elisp in general,
00:34:17.640 --> 00:34:22.480
but it's not that much fun to work on the C side. It's
00:34:22.480 --> 00:34:26.520
complex and prone to break.
00:34:26.520 --> 00:34:32.360
So don't mind collaborating.
00:34:41.560 --> 00:34:45.960
Why the sad face?
00:34:45.960 --> 00:34:56.920
Yes, I know the lack of active development.
00:35:02.920 --> 00:35:09.400
Okay. Because yeah, so no problem. You can't know anyone or
00:35:09.400 --> 00:35:10.120
a lot of,
00:35:10.120 --> 00:35:15.280
like, it's a good thing. So I got to start it and I wanted
00:35:15.280 --> 00:35:16.200
to start,
00:35:16.200 --> 00:35:24.260
you know, people quitting the XW. I don't have problems yet
00:35:24.260 --> 00:35:26.120
. It's not that I started
00:35:26.120 --> 00:35:28.720
implementing this because I thought, ah, it's not working
00:35:28.720 --> 00:35:30.840
anymore. I need something new. It's like,
00:35:30.840 --> 00:35:37.680
it's works fine. I just did it because I thought, well, why
00:35:37.680 --> 00:35:39.720
not do something new? And because it
00:35:39.720 --> 00:35:45.180
opens new possibilities, which weren't there before, or at
00:35:45.180 --> 00:35:47.320
least I didn't know of them.
00:35:47.320 --> 00:35:58.920
Okay. How could I put this? Okay. If it's ready for no, as
00:35:58.920 --> 00:36:00.440
I will promote it. If it's
00:36:00.440 --> 00:36:06.030
ready for normal usement, like you can just install it and
00:36:06.030 --> 00:36:09.480
use it for an everyday driver
00:36:09.480 --> 00:36:12.150
and have you do it. You would X session file and can just
00:36:12.150 --> 00:36:14.840
start it up. It won't be an X session
00:36:14.840 --> 00:36:18.660
file because that's X and that's a thing of the past and,
00:36:18.660 --> 00:36:20.200
but something similar.
00:36:20.200 --> 00:36:26.320
I could imagine posting, like, I don't know, he makes lists
00:36:26.320 --> 00:36:28.280
, Reddit, something like this, but
00:36:29.160 --> 00:36:33.240
until then, like the code I will release now, it's just
00:36:33.240 --> 00:36:34.200
experimental and
00:36:34.200 --> 00:36:41.710
it's for the people who want to get involved and, or want
00:36:41.710 --> 00:36:43.320
to do their own thing with it,
00:36:43.320 --> 00:36:48.130
use the client to automate sway or so for them. It's really
00:36:48.130 --> 00:36:49.640
interesting.
00:36:50.200 --> 00:36:50.200
00:36:50.200 --> 00:37:00.200
[inaudible]
00:37:00.200 --> 00:37:02.760
Yes, I know. Like you,
00:37:02.760 --> 00:42:20.290
okay, this sway.el, I have to look at it, but I don't think
00:42:20.290 --> 00:37:15.000
now is a good idea.
00:37:17.160 --> 00:37:21.680
Maybe something useful there. Thank you, PlasmaStrike and G
00:37:21.680 --> 00:37:22.520
argiola.
00:37:22.520 --> 00:37:28.450
Yes, people are moving and Valent is the future. That's the
00:37:28.450 --> 00:37:30.680
point I wanted to say. Like, I think
00:37:30.680 --> 00:37:36.840
you can stay on X, like in the future, but it's not gonna
00:37:36.840 --> 00:37:38.760
get that much development and
00:37:38.760 --> 00:37:42.520
sooner or later, like there will be new features and you
00:37:42.520 --> 00:37:44.200
won't have it in the old one and stuff
00:37:44.200 --> 00:37:48.690
like that. And for Emacs to be viable as a window manager
00:37:48.690 --> 00:37:51.560
in this whole computing environment, or as
00:37:51.560 --> 00:37:56.810
I said, a Lispy Linux desktop, I think it needs to have
00:37:56.810 --> 00:37:59.000
this Valent capability and
00:37:59.000 --> 00:38:08.680
that's the way for it to get it.
00:38:09.960 --> 00:38:09.960
00:38:09.960 --> 00:38:21.960
[inaudible]
00:38:21.960 --> 00:38:28.510
I'm just reading the IRC log and someone wrote, I was
00:38:28.510 --> 00:38:32.600
amazed to see the video inside Emacs.
00:38:32.600 --> 00:38:44.280
Thank you. That was meant to be amazing. Yeah, thank you.
00:38:45.560 --> 00:38:45.560
00:38:45.560 --> 00:38:45.640
[inaudible]
00:38:46.920 --> 00:38:46.920
00:38:46.920 --> 00:38:47.000
[inaudible]
00:38:48.280 --> 00:38:48.280
00:38:48.280 --> 00:38:48.360
[inaudible]
00:38:49.640 --> 00:38:49.640
00:38:49.640 --> 00:38:49.720
[inaudible]
00:38:51.000 --> 00:38:51.000
00:38:51.000 --> 00:38:51.080
[inaudible]
00:38:52.080 --> 00:38:52.240
[inaudible]
00:38:52.240 --> 00:38:52.400
[inaudible]
00:38:52.400 --> 00:38:52.480
[inaudible]
00:38:52.480 --> 00:38:52.640
[inaudible]
00:38:52.640 --> 00:38:52.720
[inaudible]
00:38:52.720 --> 00:38:52.800
[inaudible]
00:38:52.800 --> 00:38:52.880
[inaudible]
00:38:52.880 --> 00:38:52.960
[inaudible]
00:38:52.960 --> 00:38:53.040
[inaudible]
00:38:53.040 --> 00:38:53.120
[inaudible]
00:38:53.120 --> 00:38:53.200
[inaudible]
00:38:53.200 --> 00:38:53.200
[inaudible]
00:38:53.200 --> 00:38:53.280
[inaudible]
00:38:53.280 --> 00:38:53.360
[inaudible]
00:38:53.360 --> 00:38:53.440
[inaudible]
00:38:53.440 --> 00:38:53.520
[inaudible]
00:38:53.520 --> 00:38:53.600
[inaudible]
00:38:53.600 --> 00:38:53.680
[inaudible]
00:38:53.680 --> 00:38:53.760
[inaudible]
00:38:53.760 --> 00:38:53.840
[inaudible]
00:38:53.840 --> 00:38:53.920
[inaudible]
00:38:53.920 --> 00:38:54.000
[inaudible]
00:38:54.000 --> 00:38:54.080
[inaudible]
00:38:54.080 --> 00:38:54.160
[inaudible]
00:38:54.160 --> 00:38:54.160
[inaudible]
00:38:54.160 --> 00:38:54.240
[inaudible]
00:38:54.240 --> 00:38:54.240
[inaudible]
00:38:54.240 --> 00:38:54.320
[inaudible]
00:38:54.320 --> 00:38:54.400
[inaudible]
00:38:54.400 --> 00:38:54.480
[inaudible]
00:38:54.480 --> 00:38:54.560
[inaudible]
00:38:54.560 --> 00:38:54.640
[inaudible]
00:38:54.640 --> 00:38:54.640
[inaudible]
00:38:54.640 --> 00:38:54.720
[inaudible]
00:38:54.720 --> 00:38:54.720
[inaudible]
00:38:54.720 --> 00:38:54.800
[inaudible]
00:38:54.800 --> 00:38:54.880
[inaudible]
00:38:54.880 --> 00:38:54.960
[inaudible]
00:38:54.960 --> 00:38:55.040
[inaudible]
00:38:55.040 --> 00:38:55.120
[inaudible]
00:38:55.120 --> 00:39:20.000
[inaudible]
00:39:20.000 --> 00:39:20.080
[inaudible]
00:39:20.080 --> 00:39:20.160
[inaudible]
00:39:20.160 --> 00:39:20.240
[inaudible]
00:39:20.800 --> 00:39:20.800
00:39:20.800 --> 00:39:25.920
Okay, Emax could already do. I'm just reading the IRC
00:39:25.920 --> 00:39:46.400
because I don't know what else to say right now.
00:39:46.400 --> 00:39:57.040
[inaudible]
00:39:57.040 --> 00:40:00.880
Yeah, it's nice to see so many people saying thank you and
00:40:00.880 --> 00:40:07.600
at least I read it like two times now. So yeah, I'm pleased
00:40:07.600 --> 00:40:10.160
to see this and the interest in
00:40:10.160 --> 00:40:16.400
gender.
00:40:16.400 --> 00:40:26.640
[inaudible]
00:40:26.640 --> 00:40:38.640
[inaudible]
00:40:38.640 --> 00:40:49.370
Okay, I see there's still some people typing and it's a lot
00:40:49.370 --> 00:40:52.240
of more thank yous and yeah,
00:40:52.240 --> 00:41:00.980
thank you. I'm pleased and I will publish stuff like if it
00:41:00.980 --> 00:41:06.320
's usable. I want to use it myself,
00:41:06.320 --> 00:41:13.410
so if you're in luck, you can use it too. And let's see, I
00:41:13.410 --> 00:41:18.160
think I wrap up this Q&A here and
00:41:18.160 --> 00:41:22.780
yeah, thank you for the discussion, for your questions and
00:41:22.780 --> 00:41:27.280
your interest and have a nice rest
00:41:27.280 --> 00:41:48.950
of EmaxConf. Yeah, bye. I'm just going to leave the room or
00:41:48.950 --> 00:41:51.760
microphone or go back to EmaxConf.
00:41:55.360 --> 00:41:56.480
Sounds good. Thanks again.
00:41:56.480 --> 00:42:00.320
Ah, you're still there.
00:42:00.320 --> 00:42:03.760
Hey, yeah, I just got back for a second.
00:42:03.760 --> 00:42:05.380
Okay.
00:42:05.380 --> 00:42:08.960
Yeah, just wanted to say thanks for the great talk and I'll
00:42:08.960 --> 00:42:10.720
definitely be watching it and the Q&A.
00:42:10.720 --> 00:42:13.280
And yeah, it's very exciting stuff.
00:42:13.280 --> 00:42:17.350
Yeah, thank you. I got the feedback now. It's exciting. I
00:42:17.350 --> 00:42:20.400
think so too. So yeah,
00:42:20.400 --> 00:42:24.160
have a nice time at EmaxConf and see you next time. Bye.
00:42:24.160 --> 00:42:27.920
Thank you. You as well. See you around. Bye.
00:42:27.920 --> 00:42:28.420
Bye.
00:42:30.420 --> 00:42:30.420
00:42:30.420 --> 00:42:30.920
Bye.
00:42:32.920 --> 00:42:32.920
00:42:32.920 --> 00:42:33.420
Bye.
00:42:35.420 --> 00:42:35.420
00:42:35.420 --> 00:42:35.920
Bye.
00:42:37.920 --> 00:42:37.920
00:42:37.920 --> 00:42:38.420
Bye.
00:42:38.420 --> 00:42:46.420
Bye.
