add answers captionsHEADmaster

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.