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.