diff options
Diffstat (limited to '2024/captions/emacsconf-2024-pgmacs--pgmacs-browsing-and-editing-postgresql-databases-from-emacs--eric-marsden--answers.vtt')
| -rw-r--r-- | 2024/captions/emacsconf-2024-pgmacs--pgmacs-browsing-and-editing-postgresql-databases-from-emacs--eric-marsden--answers.vtt | 873 |
1 files changed, 873 insertions, 0 deletions
diff --git a/2024/captions/emacsconf-2024-pgmacs--pgmacs-browsing-and-editing-postgresql-databases-from-emacs--eric-marsden--answers.vtt b/2024/captions/emacsconf-2024-pgmacs--pgmacs-browsing-and-editing-postgresql-databases-from-emacs--eric-marsden--answers.vtt new file mode 100644 index 00000000..c361ae62 --- /dev/null +++ b/2024/captions/emacsconf-2024-pgmacs--pgmacs-browsing-and-editing-postgresql-databases-from-emacs--eric-marsden--answers.vtt @@ -0,0 +1,873 @@ +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. |