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.
