WEBVTT 00:00:00.000 --> 00:00:10.839 And I believe we are live. Hi, Eric, how are you doing? Very 00:00:10.840 --> 00:00:15.599 well, thanks. It's a pleasure to have you as one of our 00:00:15.600 --> 00:00:19.639 speakers but it's also very nice to see you present about 00:00:19.640 --> 00:00:24.239 pgmacs because I found your talk to be very didactic and very 00:00:24.240 --> 00:00:26.479 visual. So thank you for taking the time to do a very nice 00:00:26.480 --> 00:00:31.079 presentation. I wanted to give the opportunity as I do with 00:00:31.080 --> 00:00:36.279 other speakers to maybe talk about some stuff that you could 00:00:36.280 --> 00:00:39.279 not include into the talk because of the format. So is there 00:00:39.280 --> 00:00:41.319 anything you'd like to share with the viewers that you 00:00:41.320 --> 00:00:45.439 weren't able to include? 00:00:45.440 --> 00:00:50.719 Oh, I think I gave most of the most of the relevant 00:00:50.720 --> 00:00:54.759 information. This is a fairly young application. I've been 00:00:54.760 --> 00:00:58.159 developing this since roughly the beginning of the year. So 00:00:58.160 --> 00:01:02.879 there are probably some rough edges that people will run 00:01:02.880 --> 00:01:07.479 into if they use Postgres differently from what I do. Or they 00:01:07.480 --> 00:01:10.919 hear maybe conflicts with some other Emacs packages that 00:01:10.920 --> 00:01:14.959 people use that I don't use. So I would really welcome people 00:01:14.960 --> 00:01:19.359 trying it out and sending out bug reports if they do 00:01:19.360 --> 00:01:23.479 encounter some. Yeah, I mean, it's usually... Go on, 00:01:23.480 --> 00:01:29.079 please. Yeah, that would certainly help to make sure it's 00:01:29.080 --> 00:01:31.599 nice and robust. And of course, if you're letting this loose 00:01:31.600 --> 00:01:35.959 on some production database that you might have, you want 00:01:35.960 --> 00:01:41.239 this to be quite robust, obviously. Yeah, indeed. Because 00:01:41.240 --> 00:01:43.879 usually, you know, when you start publishing packages like 00:01:43.880 --> 00:01:46.599 this, that's when you realize that it has bad interaction 00:01:46.600 --> 00:01:49.759 with other modes in the Emacs of other persons. But 00:01:49.760 --> 00:01:52.039 especially when you're dealing with databases, you also 00:01:52.040 --> 00:01:54.639 realize that the domain space of what you're trying to do 00:01:54.640 --> 00:01:58.999 with your mode also is hugely dependent on what people have 00:01:59.000 --> 00:02:03.839 in their database, which schema they have. So, indeed, if 00:02:03.840 --> 00:02:05.839 you have been interested, and I think plenty of people have 00:02:05.840 --> 00:02:09.039 been interested by what you've presented, part of the 00:02:09.040 --> 00:02:11.679 reason a software becomes great is that you've got plenty of 00:02:11.680 --> 00:02:14.759 people making bug reports and making sure that all the 00:02:14.760 --> 00:02:18.799 faults have been ironed out. So, you know what your task is. I 00:02:18.800 --> 00:02:21.319 will also ask you, particularly right now, people 00:02:21.320 --> 00:02:24.519 currently viewing, to add your questions on the pad as 00:02:24.520 --> 00:02:27.639 usual, because you've had plenty of nice reactions, but I'm 00:02:27.640 --> 00:02:30.799 sure you have plenty of questions as well. So Eric, what I'll 00:02:30.800 --> 00:02:33.759 be doing, I'll be reading you the questions so that it's a 00:02:33.760 --> 00:02:37.439 little more didactic. Starting with the first one. This is NOTE Q: Do you know if PGmacs works with TRAMP? 00:02:37.440 --> 00:02:41.079 brilliant, thank you. Do you know if pgmacs works with TRAMP? 00:02:41.080 --> 00:02:44.119 I often use TRAMP multi-hop to access databases both 00:02:44.120 --> 00:02:46.959 remotely when accessing via bastion server and locally 00:02:46.960 --> 00:02:49.639 when using OCI containers. I believe you've already 00:02:49.640 --> 00:02:53.079 answered but if you could just perhaps read your answer as 00:02:53.080 --> 00:02:58.799 well for everyone to benefit from it. Yep, sure, that's my 00:02:58.800 --> 00:03:02.319 comment indeed. So I haven't currently implemented any 00:03:02.320 --> 00:03:07.559 TRAMP support. I'm not sure that TRAMP is really useful for 00:03:07.560 --> 00:03:11.439 this type of situation, because as I understand it, TRAMP is 00:03:11.440 --> 00:03:17.159 establishing SSH connections itself to remote servers. 00:03:17.160 --> 00:03:22.519 pgmacs is doing the same thing, so it doesn't currently have 00:03:22.520 --> 00:03:27.399 any support for hooking in with the TRAMP support. Right. 00:03:27.400 --> 00:03:31.439 Pardon me if I missed the presentation. Oh, go on, please. I 00:03:31.440 --> 00:03:34.359 guess you could set up an SSH tunnel. It does work with an SSH 00:03:34.360 --> 00:03:39.919 tunnel, obviously, but there's no support for hooking into 00:03:39.920 --> 00:03:43.799 an SSH tunnel that TRAMP might be able to create. I'm not sure 00:03:43.800 --> 00:03:46.959 TRAMP actually uses SSH tunnels rather than direct 00:03:46.960 --> 00:03:51.439 commands, but anyway. Yeah, I think that might be useful. 00:03:51.440 --> 00:03:54.759 Yeah, I don't know either. I don't have the answer whether 00:03:54.760 --> 00:03:59.039 TRAMP actually can create tunnels like this. I'm usually 00:03:59.040 --> 00:04:02.039 used to TRAMP connecting to an endpoint, be it a directory or 00:04:02.040 --> 00:04:06.239 a file, and the tunnel is just you accessing the file. But 00:04:06.240 --> 00:04:08.959 usually, if you're trying to access a remote Postgres 00:04:08.960 --> 00:04:12.039 database, you would probably manage the port forwarding in 00:04:12.040 --> 00:04:15.199 a separate terminal just to be able to make sure that 00:04:15.200 --> 00:04:17.759 everything maps correctly to your machine, and then you 00:04:17.760 --> 00:04:21.959 would launch pgmacs with the forward port information. 00:04:21.960 --> 00:04:25.519 That's, I assume, how you would do it anyway. But yeah, I 00:04:25.520 --> 00:04:29.119 mean, if you could specify what you mean by TRAMP support and 00:04:29.120 --> 00:04:31.839 if you have something specific in mind, I'm talking to the 00:04:31.840 --> 00:04:35.119 questioner, feel free to specify and we'll see if you can 00:04:35.120 --> 00:04:38.239 answer it. But in the meantime, moving to the next question. NOTE Q: How did you come up with this brilliant idea? 00:04:38.240 --> 00:04:41.999 Great work, I'm impressed. How did you come up with this 00:04:42.000 --> 00:04:49.079 brilliant idea, I assume, to create pgmacs? Well, thanks for 00:04:49.080 --> 00:04:52.839 the compliment. It's a lot of fun developing something 00:04:52.840 --> 00:04:57.799 which is, as I said, such a small amount of code and which 00:04:57.800 --> 00:05:02.359 provides quite a bit of useful functionality. In 00:05:02.360 --> 00:05:06.839 particular, if you compare it with existing Terminal mode 00:05:06.840 --> 00:05:12.799 applications for manipulating Postgres data, they are 00:05:12.800 --> 00:05:19.279 not as extensible as Emacs is naturally. So I actually got 00:05:19.280 --> 00:05:23.439 the idea for developing this when I first tested out the 00:05:23.440 --> 00:05:27.439 SQLite mode, which is available in Emacs 29.1. 00:05:27.440 --> 00:05:31.879 And I thought, well, that's really quite impressive. And it 00:05:31.880 --> 00:05:37.359 allows you to delete rows and insert content and so on. And I 00:05:37.360 --> 00:05:42.359 was thinking, yeah, Emacs is a, is a useful environment to do 00:05:42.360 --> 00:05:50.079 that. And since several years ago, when I was doing my PhD, so 00:05:50.080 --> 00:05:53.999 to avoid doing my PhD, I was developing Emacs, I was 00:05:54.000 --> 00:05:58.399 developing stuff in Emacs Lisp and one of the libraries I 00:05:58.400 --> 00:06:02.959 developed was an interface to Postgres over the network. So 00:06:02.960 --> 00:06:08.039 that's the library called pg.el, which is used by pgmacs to 00:06:08.040 --> 00:06:14.239 access Postgres and to do all the parsing of data which 00:06:14.240 --> 00:06:19.279 arrives in Postgres formats into the Emacs Lisp into the 00:06:19.280 --> 00:06:22.999 Emacs corresponding versions. So, for example, integers 00:06:23.000 --> 00:06:25.399 are passed as Emacs integers, floating point numbers as 00:06:25.400 --> 00:06:30.839 floating point numbers, and so on. Right, yeah. I mean, it's 00:06:30.840 --> 00:06:34.439 pretty needed, obviously, when you have such a tooling like 00:06:34.440 --> 00:06:37.359 this, to make sure that the type conversion works properly, 00:06:37.360 --> 00:06:39.879 because the types that you have in Postgres do not 00:06:39.880 --> 00:06:43.879 necessarily map over to what we have in Emacs. Like, I'm 00:06:43.880 --> 00:06:49.239 interested, how would you handle g's and b columns in pgmacs? 00:06:49.240 --> 00:06:55.039 JSON is mapped to an edis dict, a dictionary. 00:06:55.040 --> 00:07:03.759 It depends on the top level object type for your JSON column. 00:07:03.760 --> 00:07:07.599 If it's an array, it's mapped to an Emacs Lisp array. If it's a 00:07:07.600 --> 00:07:12.639 dict, which is most common, it's mapped to an Emacs Lisp 00:07:12.640 --> 00:07:17.679 dictionary. All right, well it makes perfect sense. So I can 00:07:17.680 --> 00:07:21.839 break in with a question. Thanks, I just helped myself to the 00:07:21.840 --> 00:07:26.159 BBB privilege of kind of running around backstage, being a 00:07:26.160 --> 00:07:31.679 helper backstage. So thanks for your awesome talk, Eric. I 00:07:31.680 --> 00:07:36.719 super appreciated it. You know, I noticed that you that 00:07:36.720 --> 00:07:43.159 you're on a slightly older version of Emacs that I deal with 00:07:43.160 --> 00:07:49.519 in helping with producing the Windows binaries I run into 00:07:49.520 --> 00:07:53.839 and with some other stuff I do. I'm dealing with that 00:07:53.840 --> 00:07:56.919 friction of sometimes I've got some work of my own that 00:07:56.920 --> 00:07:59.719 applies against a specific version of Emacs and it's a bunch 00:07:59.720 --> 00:08:02.519 of work to think about moving it forward. Just curious if you 00:08:02.520 --> 00:08:06.479 started thinking about that or if you routine, if that's a 00:08:06.480 --> 00:08:09.919 routine that you haven't done or there's something maybe 00:08:09.920 --> 00:08:14.599 specifically going on with, you know, with trunk 00:08:14.600 --> 00:08:20.599 development that looks intimidating to deal with. Thanks 00:08:20.600 --> 00:08:24.959 for the comment. I'm not sure I'm using a really old version 00:08:24.960 --> 00:08:29.239 for Windows. I don't really develop often on Windows, but I I 00:08:29.240 --> 00:08:32.639 occasionally check that it works, and I took a screenshot 00:08:32.640 --> 00:08:34.799 that I included in the slides here, but I think I'm using 00:08:34.800 --> 00:08:40.559 29.4, the current version on Windows. I thought I saw 29.1, 00:08:40.560 --> 00:08:48.839 so that's probably my, I probably missed it when it went by. 00:08:48.840 --> 00:08:54.879 My bad. No, no, I use it via the choco package updater so that 00:08:54.880 --> 00:08:58.479 updates the Emacs version quite easily on Windows. So 00:08:58.480 --> 00:09:03.079 thanks for your work on maintaining Windows binaries. I 00:09:03.080 --> 00:09:07.519 realize that was- I sit downstream at the end of a lot of other 00:09:07.520 --> 00:09:11.399 people's hard work and then just focus on trying to QA well 00:09:11.400 --> 00:09:15.559 and help catch problems early. It's really fun. But of 00:09:15.560 --> 00:09:16.399 course, my pleasure. 00:09:16.400 --> 00:09:21.799 Coming back to the previous question, so the the 00:09:21.800 --> 00:09:26.919 questionnaire actually provided a little more context. So NOTE TRAMP continued 00:09:26.920 --> 00:09:30.599 with docker.el, kubel, etc, it's often possible to, for 00:09:30.600 --> 00:09:33.919 example, select a container pod or whatever that is hosted 00:09:33.920 --> 00:09:36.639 on the machine you've connected to via TRAMP, such as 00:09:36.640 --> 00:09:41.799 Podman, colon image colon path and trigger a terminal shell 00:09:41.800 --> 00:09:44.959 as well as pull forward on other similar things. It'd be nice 00:09:44.960 --> 00:09:47.679 to be able to use this tool in a similar way since it would open 00:09:47.680 --> 00:09:49.919 up the ability to use it with complex connection 00:09:49.920 --> 00:09:53.679 configuration. Doing SSH tunnel manually is of course 00:09:53.680 --> 00:09:56.879 totally fine in practice and if it is actually the case 00:09:56.880 --> 00:10:01.319 personally when I need to remote into a kubernetes machine I 00:10:01.320 --> 00:10:05.239 use POSIX script that I use on most of my machines but I don't 00:10:05.240 --> 00:10:08.599 do it inside Emacs. But yeah, if such a thing is possible via 00:10:08.600 --> 00:10:11.039 TRAMP, it definitely feels like it would be possible to do 00:10:11.040 --> 00:10:14.919 something similar in pgmacs. So perhaps that's a path of 00:10:14.920 --> 00:10:19.559 investigation for you that has opened up. Yeah, thanks for 00:10:19.560 --> 00:10:22.759 these comments. I'll look into that indeed if people have 00:10:22.760 --> 00:10:26.159 some shortcuts registered in TRAMP. So not for a terminal, 00:10:26.160 --> 00:10:29.599 because pgmacs won't work through a terminal, but through a 00:10:29.600 --> 00:10:33.439 port forward, then that would be convenient. I'll see how 00:10:33.440 --> 00:10:38.639 easy that is to set up. Yeah, I'm pretty sure the way it works 00:10:38.640 --> 00:10:41.279 is that it starts some processes in the background in Emacs 00:10:41.280 --> 00:10:45.359 just to either maintain the port forward or to maybe remap 00:10:45.360 --> 00:10:49.239 some kubecon things or whatever. So with pgmacs, 00:10:49.240 --> 00:10:51.879 considering complex pipelines to get to the end 00:10:51.880 --> 00:10:54.679 destination, it feels like it would be possible to do 00:10:54.680 --> 00:10:57.439 something. But perhaps it's not the responsibility of 00:10:57.440 --> 00:11:00.199 pgmacs, perhaps it's the responsibility of another, 00:11:00.200 --> 00:11:03.639 perhaps something that would target TRAMP more so than 00:11:03.640 --> 00:11:08.399 pgmacs. But it's nice to see again how the beauty of Emacs 00:11:08.400 --> 00:11:12.119 is that everything is Elisp at the end, and the way they 00:11:12.120 --> 00:11:16.079 interact, you might want to question yourself whether this 00:11:16.080 --> 00:11:18.919 belongs more to pgmacs or more to TRAMP, but at the end of the 00:11:18.920 --> 00:11:22.439 day, both applications will be able to benefit from the 00:11:22.440 --> 00:11:24.759 functions of the other. So that's the beauty of the 00:11:24.760 --> 00:11:29.159 philosophy right here. I do see... Absolutely, I agree. 00:11:29.160 --> 00:11:32.279 Sorry, before we move to different questions, an 00:11:32.280 --> 00:11:36.759 additional point. I should point out that to warn people 00:11:36.760 --> 00:11:41.159 that probably running over an SSH tunnel is going to be a bit 00:11:41.160 --> 00:11:46.839 slow. I mostly use it on my own machine via a local Unix 00:11:46.840 --> 00:11:50.439 connection. And for some reason that I haven't understood, 00:11:50.440 --> 00:11:55.119 pgmacs is quite a bit slower when it's even connecting to the 00:11:55.120 --> 00:12:00.359 same database on the local machine, but via Emacs' network 00:12:00.360 --> 00:12:05.039 support instead of via the Unix socket support. There is 00:12:05.040 --> 00:12:11.639 like a factor 10 difference in throughput and in latency. I 00:12:11.640 --> 00:12:15.839 don't really understand why currently, because it's using 00:12:15.840 --> 00:12:21.919 exactly the same Emacs Lisp level primitives. And when you 00:12:21.920 --> 00:12:24.799 do this using other libraries like libpq, which is the 00:12:24.800 --> 00:12:30.639 Postgres standard official library for connecting to 00:12:30.640 --> 00:12:34.319 Postgres, there's not such a performance difference. So 00:12:34.320 --> 00:12:39.759 there's probably something that is not working perfectly 00:12:39.760 --> 00:12:43.879 in the Emacs network support. I'll have to see whether I can 00:12:43.880 --> 00:12:48.679 investigate how to improve that performance. Yeah, I'm 00:12:48.680 --> 00:12:52.999 going to say it sounds like a great bug to have because it 00:12:53.000 --> 00:12:57.319 feels like it will allow you to dig deeper into Emacs to 00:12:57.320 --> 00:12:59.679 understand what is going on here. Because as you said, 00:12:59.680 --> 00:13:01.519 normally it's supposed to work exactly the same, 00:13:01.520 --> 00:13:04.319 especially if it's still in your local machine, but it 00:13:04.320 --> 00:13:07.919 doesn't. Personally, that's the kind of bug that I really 00:13:07.920 --> 00:13:11.199 like and that I'd like to spend more time investigating. So 00:13:11.200 --> 00:13:14.759 perhaps you might think otherwise, but I wish you luck on the 00:13:14.760 --> 00:13:18.599 debugging with this particular matter. All right, moving 00:13:18.600 --> 00:13:21.519 to the last question that we have and then we'll probably go 00:13:21.520 --> 00:13:22.965 on a little bit of a break. NOTE Q: Is sqlite-mode also capable of all of this functionality (table relations, etc)? If not, will it be possible to abstract out this functionality from pgmacs somehow? 00:13:22.966 --> 00:13:25.399 Question. Is SQLite mode also 00:13:25.400 --> 00:13:28.439 capable of all of this functionality, table relations, 00:13:28.440 --> 00:13:31.559 etc.? If not, would it be possible to abstract out this 00:13:31.560 --> 00:13:33.279 functionality from pgmacs somehow? 00:13:33.280 --> 00:13:41.319 So I'm not very familiar with SQLite because I don't really 00:13:41.320 --> 00:13:46.439 use it very much myself. I'm not sure I can answer that 00:13:46.440 --> 00:13:53.079 question. Sorry about that. I think it is probably a bit more 00:13:53.080 --> 00:13:56.639 basic because SQLite itself is quite a bit more basic in 00:13:56.640 --> 00:14:01.639 terms of the types of indexes it's able to support and the 00:14:01.640 --> 00:14:09.199 types of constraints it's able to support. Is it relevant to 00:14:09.200 --> 00:14:13.799 create an abstract API for connecting to databases? I think 00:14:13.800 --> 00:14:19.639 there is already actually a library that abstracts out from 00:14:19.640 --> 00:14:25.439 SQLite and Postgres. Postgres, when you connect to it via a 00:14:25.440 --> 00:14:29.159 PSQL subsystem, 00:14:29.160 --> 00:14:38.439 it might be worthwhile doing that, but there are often a few 00:14:38.440 --> 00:14:42.279 minor differences in SQL syntax and so on between 00:14:42.280 --> 00:14:45.879 databases. So it might be difficult to have something that 00:14:45.880 --> 00:14:53.159 really works with generic queries in an effective way. All 00:14:53.160 --> 00:14:58.239 these SQL dialects are a little bit different, 00:14:58.240 --> 00:15:02.319 unfortunately. So there was another question about I was 00:15:02.320 --> 00:15:06.510 just going to read out the next question. NOTE Q: Would it be possible to move it into Emacs tree? Are the maintainers interested in it? 00:15:06.511 --> 00:15:07.519 So have you thought 00:15:07.520 --> 00:15:12.559 about integrating your work into the Emacs tree? Do you know 00:15:12.560 --> 00:15:17.599 if people are interested? This was a question from the past. 00:15:17.600 --> 00:15:24.639 Yeah, I think it's probably a bit young to do so, so far. 00:15:24.640 --> 00:15:30.119 I'm updating it quite regularly. Maybe once it's more 00:15:30.120 --> 00:15:35.399 stabilized, I wouldn't necessarily object to this. I have 00:15:35.400 --> 00:15:38.559 some sort of philosophical objections to giving away my 00:15:38.560 --> 00:15:42.519 copyright, so I'm not sure that will actually be possible. 00:15:42.520 --> 00:15:48.079 Oh, that'd be interesting. I'd love to get you on maybe a 00:15:48.080 --> 00:15:51.639 panel talk about that sometime. Something I'd think about. 00:15:51.640 --> 00:15:55.999 Well, from a very simple point of view, I think that the 00:15:56.000 --> 00:16:01.159 copyright and the system works well with the existing 00:16:01.160 --> 00:16:05.319 license and without a license transfer, so I don't feel that 00:16:05.320 --> 00:16:07.766 the, sorry, without a copyright transfer, 00:16:07.767 --> 00:16:14.679 I don't feel that the copyright transfer is really a necessary step for 00:16:14.680 --> 00:16:21.639 taking things away from maintainers. It feels like asking 00:16:21.640 --> 00:16:26.559 the maintainers to give up on some of their copyright... 00:16:26.560 --> 00:16:29.999 Indeed. Yeah, I see where that's a little beyond our scope, 00:16:30.000 --> 00:16:33.519 but it's a fascinating topic and I appreciate your sharing 00:16:33.520 --> 00:16:36.959 your views there. I mean, that sounds like a whole topic of 00:16:36.960 --> 00:16:41.599 its own, frankly. 00:16:41.600 --> 00:16:47.039 Yeah. Corwin, do you want to fill the last question? Sure. So 00:16:47.040 --> 00:16:52.039 the question was, I almost missed this one, so glad I didn't. 00:16:52.040 --> 00:16:53.849 This may have been answered already. NOTE Q: What do you use for the in-buffer tables? Vtable? 00:16:53.850 --> 00:16:55.159 What do you use for 00:16:55.160 --> 00:17:00.039 in-buffer tables? Do you use vtable? Yep. Thanks for the 00:17:00.040 --> 00:17:04.599 question. It is indeed vtable. However, it's not really 00:17:04.600 --> 00:17:10.919 vtable. It's a fork that I made, which is called pgmix table. 00:17:10.920 --> 00:17:17.199 because Vtable doesn't have exactly the right 00:17:17.200 --> 00:17:22.119 functionality in particular for recoloring rows when you 00:17:22.120 --> 00:17:28.239 add a row. So I've currently forked this. I'm thinking about 00:17:28.240 --> 00:17:36.359 giving those back as patches to Vtable, plausibly. 00:17:36.360 --> 00:17:40.719 I know that there is some ongoing work also on vTable in the 00:17:40.720 --> 00:17:45.839 core. So I'll have to look at what is plausible to feed back 00:17:45.840 --> 00:17:46.719 into the main version. 00:17:46.720 --> 00:17:55.199 All right, great. I think we are nearing the end of the Q&A. We 00:17:55.200 --> 00:17:59.079 are due to move to the next talk in about three minutes now. I 00:17:59.080 --> 00:18:02.719 can fill 30 seconds or a minute of that with I guess one more 00:18:02.720 --> 00:18:05.079 maybe back and forth and I'll try to be quicker this time. 00:18:05.080 --> 00:18:08.879 First of all, thanks for your kind remarks. But my question 00:18:08.880 --> 00:18:11.839 wasn't really about Windows so much, it was just how I'm 00:18:11.840 --> 00:18:16.639 relating... So have you, let me put it more simply, have you NOTE Integrating with Emacs 30? 00:18:16.640 --> 00:18:20.639 started looking at integrating with Emacs 30 or with the 00:18:20.640 --> 00:18:24.679 master branch at all? Do you have any sense of how much work 00:18:24.680 --> 00:18:27.079 it's going to be for you to carry things forward there? I've 00:18:27.080 --> 00:18:31.039 tested it with the pre-release, yes. I mean, just a very 00:18:31.040 --> 00:18:35.079 basic testing and everything works perfectly. There's 00:18:35.080 --> 00:18:39.799 really no... There was no difference that I have noticed 00:18:39.800 --> 00:18:46.279 between 29.4 and the 30 pre-release on the aspects that I use 00:18:46.280 --> 00:18:48.959 at least in Emacs. Neato. 00:18:48.960 --> 00:18:56.439 That was it, Leo. Thanks for letting me back in for one more 00:18:56.440 --> 00:18:58.799 bite at the apple there. And I appreciate everybody tuning 00:18:58.800 --> 00:19:03.479 in and participating in the Q&A and this awesome talk. 00:19:03.480 --> 00:19:06.879 Thanks for your questions. That was great. Yeah, and thank 00:19:06.880 --> 00:19:10.319 you for answering them and for the presentation as well. So 00:19:10.320 --> 00:19:14.199 we'll be moving in about two minutes to the next talk, which 00:19:14.200 --> 00:19:20.159 is pre-recorded as well. Well, we didn't really give you the 00:19:20.160 --> 00:19:29.399 chance, Eric, to have the last word. So do you have any last 00:19:29.400 --> 00:19:29.799 word? 00:19:29.800 --> 00:19:34.479 please try it out, try out pgmacs and send some feedback 00:19:34.480 --> 00:19:39.279 that'll help improve it over time. Sure, great. Well, thank 00:19:39.280 --> 00:19:41.559 you so much, Eric, for taking the time to come to the 00:19:41.560 --> 00:19:45.999 conference, and we'll see you soon. Thank you. Bye, 00:19:46.000 --> 00:19:50.279 everyone. Bye. And we'll be live with the next talk in about 1 00:19:50.280 --> 00:19:53.119 minute 30. So we'll take a little bit of a breather, go make 00:19:53.120 --> 00:19:56.599 some coffee, go take a bio break. We'll be back soon. See you 00:19:56.600 --> 00:20:01.880 in a bit.