path: root/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--answers.vtt

WEBVTT

00:00:00.000 --> 00:00:05.079
You sound great. And on the stream, my eyeball says it looks

00:00:05.080 --> 00:00:08.239
great with Leo doing the streaming. So I say let's dive right

00:00:08.240 --> 00:00:12.639
in. You got a long, huge line. And in order to be a little more

00:00:12.640 --> 00:00:16.279
dialectical, I'll be reading the questions. So first

NOTE Q: which-key was a third-party package for a long time. Is there work to bring any other popular packages into core Emacs for Emacs 31+? (magit, counsel, etc)

00:00:16.280 --> 00:00:18.559
question, which key was a third party package for a long

00:00:18.560 --> 00:00:21.879
time? Is there work to bring any other popular packages into

00:00:21.880 --> 00:00:25.399
the core of Emacs for Emacs 31 plus, like Magit or Counsel?

00:00:25.400 --> 00:00:30.279
Uh, right. I already answered that one on the, as you can see,

00:00:30.280 --> 00:00:33.999
uh, right. Yeah. Do you want to quickly read the answer so

00:00:34.000 --> 00:00:38.439
that everyone, I just can read it out again. Um, as far as I

00:00:38.440 --> 00:00:41.159
remember, the one package that was being discussed just

00:00:41.160 --> 00:00:43.999
around the time that the Emacs 30 branch was cut was macro

00:00:44.000 --> 00:00:47.599
step. That's the package that was like, does an overlay, uh,

00:00:47.600 --> 00:00:51.479
replaces a macro with the macro expansion using overlays.

00:00:51.480 --> 00:00:53.799
So you don't have to pop up another buffer, modified,

00:00:53.800 --> 00:00:57.599
modified current buffer. But we didn't manage to address

00:00:57.600 --> 00:01:00.759
all the concerns in time for the Emacs 30 cuts and I believe

00:01:00.760 --> 00:01:03.799
it's sort of stagnated around that but it might be picked up

00:01:03.800 --> 00:01:07.399
anytime someone mentions it on Emacs Devil again. Another

00:01:07.400 --> 00:01:11.519
package question mentioned was Magit. That's a constant

00:01:11.520 --> 00:01:14.959
discussion regarding Magit. And actually, from the top of

00:01:14.960 --> 00:01:19.039
my head, I can't recall if Magit is on NonGNU ELPA or GNU ELPA

00:01:19.040 --> 00:01:22.999
right now. It's still on NonGNU ELPA.

00:01:23.000 --> 00:01:29.039
For those who don't know, only packages which are in ELPA are

00:01:29.040 --> 00:01:33.039
considered for addition, considered to be added to the

00:01:33.040 --> 00:01:36.119
Emacs core, to be bundled along with Emacs. And then there's

00:01:36.120 --> 00:01:40.519
another totally parallel discussion about having a sort of

00:01:40.520 --> 00:01:43.519
fat Emacs distribution, I call it fat Emacs distribution,

00:01:43.520 --> 00:01:48.119
where Emacs comes with a lot of ELPA packages or the

00:01:48.120 --> 00:01:55.039
pre-installed by default. Part of Emacs itself. Yeah.

00:01:55.040 --> 00:01:59.159
Maybe I could jump in with an active listening style,

00:01:59.160 --> 00:02:03.359
you know, kind of follow up question almost. You know, I

00:02:03.360 --> 00:02:07.159
understand the kind of different repositories. We have

00:02:07.160 --> 00:02:13.799
things that aren't maintained by GNU at all, you know, most

00:02:13.800 --> 00:02:17.919
notably MELPA. And then we have kind of NonGNU ELPA, which

00:02:17.920 --> 00:02:21.639
is sort of an entryway project where it's not necessarily

00:02:21.640 --> 00:02:24.759
curated, but there'll be some advice given, which you can

00:02:24.760 --> 00:02:28.159
take or leave. And that's the repository where anything

00:02:28.160 --> 00:02:32.519
that was the newer repository that represents, you know,

00:02:32.520 --> 00:02:36.319
help, you know, help, help supplied from GNU. And then

00:02:36.320 --> 00:02:41.319
there's the, actually the GNU, the GNU ELPA, what most of us

00:02:41.320 --> 00:02:46.479
are used to calling just ELPA. And that's what you're

00:02:46.480 --> 00:02:50.839
talking about there when you say,

00:02:50.840 --> 00:02:53.959
I mean, all packages on ELPA are officially considered to be

00:02:53.960 --> 00:02:56.959
part of Emacs, they're licensed under the same conditions

00:02:56.960 --> 00:03:00.359
as Emacs itself, same license, same everything. And

00:03:00.360 --> 00:03:03.719
they're more likely to be, to drop, to kind of be dropping

00:03:03.720 --> 00:03:07.839
patched. Oh yeah, it's time for this to move to core. Is that

00:03:07.840 --> 00:03:12.559
right? They have the legal conditions for that to be done.

00:03:12.560 --> 00:03:15.039
Everything's necessary from a paperwork standpoint. I

00:03:15.040 --> 00:03:17.959
mean, but other than that, there's not really a big

00:03:17.960 --> 00:03:21.159
difference between GNU ELPA and NonGNU ELPA. It's

00:03:21.160 --> 00:03:23.839
really just the main thing is this copyrights notice. So if

00:03:23.840 --> 00:03:28.519
you want to add a package to ELPA, to GNU ELPA, then all

00:03:28.520 --> 00:03:32.359
significance contributors have to have signed the FSF

00:03:32.360 --> 00:03:36.399
copyright assignment and the package script, actually the

00:03:36.400 --> 00:03:41.519
ELPA build script, checks if the copyright lines are all

00:03:41.520 --> 00:03:43.879
attributed to the Free Software Foundation.

00:03:43.880 --> 00:03:52.119
But that's not going to attach, right? So because that's not

00:03:52.120 --> 00:03:57.799
in place, it'd be a lot more work to merge it to core. I didn't

00:03:57.800 --> 00:04:01.039
hear the beginning. Nevermind. I think I understood. You

00:04:01.040 --> 00:04:05.559
made your point well. Okay. All right, moving on to the

00:04:05.560 --> 00:04:06.466
second question.

NOTE Q: Any way to get the goodness of Emacs for android with this other stuff?

00:04:06.467 --> 00:04:08.279
When thinking about using Emacs on

00:04:08.280 --> 00:04:11.279
Android, I started realizing all the other software I also

00:04:11.280 --> 00:04:15.279
want on it. For example, PDF Tools wants a small additional

00:04:15.280 --> 00:04:18.519
Emacs-specific program to be installed on, and notmuch

00:04:18.520 --> 00:04:21.359
obviously wants notmuch. Any way to get the goodness of

00:04:21.360 --> 00:04:25.639
Emacs for Android with this other stuff, using either Nix OS

00:04:25.640 --> 00:04:29.279
or Guix or nix-on-droid to make an APK with extra stuff? Are you

00:04:29.280 --> 00:04:34.439
familiar with this topic? Absolutely not. The extent to

00:04:34.440 --> 00:04:39.319
which I have used Emacs on Android was entirely

00:04:39.320 --> 00:04:43.719
demonstrated in this video, I think. In my previous video. I

00:04:43.720 --> 00:04:48.719
mean, I know it does a few scrolling stuff, but I have no idea

00:04:48.720 --> 00:04:52.719
how external stuff, because I mean, Android is, it's a Unix

00:04:52.720 --> 00:04:55.439
or it's a Linux based system, but it's really heavily

00:04:55.440 --> 00:05:01.439
modified to the preferences of Google, which includes not

00:05:01.440 --> 00:05:04.719
being able to have your own software on it. Yeah,

00:05:04.720 --> 00:05:08.799
definitely. All right, moving on to the next question. Does

00:05:08.800 --> 00:05:12.239
package-vc... Oh, no, that's fine. I mean, you can't answer

00:05:12.240 --> 00:05:15.199
all the questions. I mean, it wouldn't be fun for me

00:05:15.200 --> 00:05:15.753
otherwise.

NOTE Q: Does package-vc download a tarball from the specified git repository or clone the repository itself?

00:05:15.754 --> 00:05:17.919
Does package-vc download a tarball from the

00:05:17.920 --> 00:05:21.759
specified Git repository or clone the repository itself?

00:05:21.760 --> 00:05:25.439
It clones the repository. That's the VC part in the name.

00:05:25.440 --> 00:05:33.719
package-vc uses VC, the C-x v stuff. In Emacs 29, there's a

00:05:33.720 --> 00:05:37.679
new command called vc-clone, which in Emacs 31, it was

00:05:37.680 --> 00:05:42.479
actually exposed as an interactive command. And when you

00:05:42.480 --> 00:05:47.319
clone the repository, or when you, you can give it any URL of a

00:05:47.320 --> 00:05:50.559
Git repository or a CVS repository or subversion

00:05:50.560 --> 00:05:53.519
repository. Interestingly enough, most people only use

00:05:53.520 --> 00:05:57.559
Git, but anything that's, that implements this clone

00:05:57.560 --> 00:06:01.519
command for VC, and it could download it. So there's no

00:06:01.520 --> 00:06:05.119
tarballs involved. Which is also, one should emphasize,

00:06:05.120 --> 00:06:07.879
part of the difficulty of VC packages because when you have

00:06:07.880 --> 00:06:10.759
version control and you want to upgrade it, it might be that

00:06:10.760 --> 00:06:14.399
the upstream did a force push. For that, you make local

00:06:14.400 --> 00:06:17.519
changes and then you have to merge them upstream with the

00:06:17.520 --> 00:06:21.239
upstream changes when fetching stuff. It's one of the big

00:06:21.240 --> 00:06:23.559
downsides of version-controlled stuff, and I'm saying

00:06:23.560 --> 00:06:26.999
this as the guy who actually wrote package-vc. There's

00:06:27.000 --> 00:06:29.719
times to use it, there's advantages to it, but that's

00:06:29.720 --> 00:06:32.959
something you should keep in mind, why tarballs are

00:06:32.960 --> 00:06:37.969
interesting to have, in my opinion. Okay.

NOTE How is the new behavior of M-q in prog-mode (prog-fill-reindent-defun or something like that) different from the behavior of C-M-q (indent-pp-sexp) in older Emacs versions?

00:06:37.970 --> 00:06:39.639
How is the new

00:06:39.640 --> 00:06:42.439
behavior of M-q in prog mode, prog-fill-reindent-defun

00:06:42.440 --> 00:06:45.159
or something like that, different from the behavior

00:06:45.160 --> 00:06:48.799
of C-M-q, i.e. indent-pp-sexp in older Emacs

00:06:48.800 --> 00:06:52.199
version? My apologies if indent-pp-sexp, it's really tough to

00:06:52.200 --> 00:06:55.959
read M-x commands out loud. It's not bound to

00:06:55.960 --> 00:07:01.519
C-M-q by default, I can't tell. Let me try that command

00:07:01.520 --> 00:07:05.599
out because I've never tried it, never used it before.

00:07:05.600 --> 00:07:09.079
You know, that isn't bound by default. I bind that up myself

00:07:09.080 --> 00:07:11.759
and I have that binding. I think that's, that's not right. It

00:07:11.760 --> 00:07:15.119
says so. I mean, I'm currently executing it here in Emacs and

00:07:15.120 --> 00:07:20.839
it says you can also run the commands indent-pp-sexp with

00:07:20.840 --> 00:07:26.359
M-q, C-M-q. Apparently it is. I mean, I

00:07:26.360 --> 00:07:31.359
didn't set it myself. I don't know what's up with that. to try

00:07:31.360 --> 00:07:35.439
and move it. And then each line started with points or pretty

00:07:35.440 --> 00:07:37.239
printed. I mean, the difference, the main difference

00:07:37.240 --> 00:07:41.279
between that and the command highlighted, what's the name

00:07:41.280 --> 00:07:47.479
again? I forget it all the time. The prog-mode command.

00:07:47.480 --> 00:07:50.359
prog-fill-reindent-defun is that

00:07:50.360 --> 00:07:56.319
it checks if it's in a string or not. If it's in a string or if

00:07:56.320 --> 00:07:58.959
it's in a comma, then it will refill. Otherwise, it's going

00:07:58.960 --> 00:07:59.799
to re-indent.

00:07:59.800 --> 00:08:05.679
That's, I think, as far as I see, that's going to be the main

00:08:05.680 --> 00:08:09.599
difference. If we have some long comments somewhere. Let's

00:08:09.600 --> 00:08:15.439
try that out. Yeah, that's the difference. I just, you can't

00:08:15.440 --> 00:08:19.679
see it, but I did try it. Okay, good. Thank you. You did a

00:08:19.680 --> 00:08:22.119
wonderful job describing visually what you're doing. All

00:08:22.120 --> 00:08:26.759
right, moving on to the next question, and we have about, we

00:08:26.760 --> 00:08:28.759
have just enough time to cover the last three questions,

00:08:28.760 --> 00:08:32.239
especially because the next one, I can pretty much surmise

00:08:32.240 --> 00:08:33.143
the answer.

NOTE Q: Any plans for Emacs running in iOS?

00:08:33.144 --> 00:08:36.759
Any plans for Emacs running on iOS? Probably not

00:08:36.760 --> 00:08:40.319
because it's not, I mean, as I emphasized in the video, the

00:08:40.320 --> 00:08:43.639
Emacs port in Android is completely free. And to my

00:08:43.640 --> 00:08:45.319
knowledge, that's not something that's currently

00:08:45.320 --> 00:08:49.799
possible with iOS. You need Xcode or something like that to

00:08:49.800 --> 00:08:56.639
build iOS stuff. So that's a big no-no. I mean, maybe Apple's

00:08:56.640 --> 00:09:00.919
going to change their mind on that one. Well, I won't be the

00:09:00.920 --> 00:09:04.039
one liaising with Apple to make sure that they do, but PR

00:09:04.040 --> 00:09:07.599
welcomes, I guess, or motivated folks welcome. Second to

00:09:07.600 --> 00:09:08.647
last question.

NOTE Q: I am worried about the situation on non-free systems. There was talk about the Windows and the macOS versions being as good as unmaintained. Where do we go from here?

00:09:08.648 --> 00:09:11.719
I am worried about the situation on non-free

00:09:11.720 --> 00:09:14.519
systems. There was talk about the Windows and the macOS

00:09:14.520 --> 00:09:17.039
versions being as good as unmaintained. Where do we go from

00:09:17.040 --> 00:09:20.399
here? I gather that most users of Emacs are still on non-free

00:09:20.400 --> 00:09:24.799
platforms and will remain to be there. I don't know about the

00:09:24.800 --> 00:09:28.279
last point, if that's true, because there's no statistics

00:09:28.280 --> 00:09:35.039
on that matter. But the main, I mean, someone has to, I know

00:09:35.040 --> 00:09:37.959
that Corwin is involved with the Mac, with the Windows

00:09:37.960 --> 00:09:43.199
stuff. Modestly. Sure, I'd love to jump in, but I'm far more

00:09:43.200 --> 00:09:45.839
interested in your thoughts than mine. Please, please

00:09:45.840 --> 00:09:51.039
continue. Someone has to do the work. Eli uses, as far as I

00:09:51.040 --> 00:09:58.719
know, Eli's on the Windows XP system. So as long as he's doing

00:09:58.720 --> 00:10:02.519
that, there's going to be Windows support for one form or

00:10:02.520 --> 00:10:07.959
another, or at least DOS. All right. And now you put a quarter

00:10:07.960 --> 00:10:12.439
in me, so I'll jump right back in. That's perfect for where I

00:10:12.440 --> 00:10:14.519
guess I would take the question. To me, it's an

00:10:14.520 --> 00:10:17.439
accessibility issue. Think about it this way. Maybe that

00:10:17.440 --> 00:10:23.319
Windows XP system is what someone can afford. Likewise,

00:10:23.320 --> 00:10:27.679
from a freedom versus I have to do my job and I have to use

00:10:27.680 --> 00:10:31.679
certain technology to do my job. Maybe Emacs is what

00:10:31.680 --> 00:10:35.559
somebody can afford right? It might be the only free tool

00:10:35.560 --> 00:10:37.439
that they use and they don't have a lot of choice about the

00:10:37.440 --> 00:10:40.039
operating system that they're in most of the day. In fact,

00:10:40.040 --> 00:10:42.279
somebody could be in the situation where their computing

00:10:42.280 --> 00:10:45.839
device at work is really their internet access, right? All

00:10:45.840 --> 00:10:48.279
of those situations are possible. Therefore, I tend to

00:10:48.280 --> 00:10:53.479
assume they all exist and when I ask, you know, how much It

00:10:53.480 --> 00:10:58.039
definitely is concerning when we hear about kind of black

00:10:58.040 --> 00:11:02.079
holes in the brain trust of something like support for the

00:11:02.080 --> 00:11:06.359
Windows port. I feel like I've heard a lot of people

00:11:06.360 --> 00:11:10.959
answering that call, but the importance of that is that it

00:11:10.960 --> 00:11:14.119
doesn't stop echoing, right? Free software goes as long as

00:11:14.120 --> 00:11:16.399
there are people that are irritated enough about something

00:11:16.400 --> 00:11:20.839
to sort of come hack on it. Yeah. And the same applies to Mac

00:11:20.840 --> 00:11:25.199
OS. But I don't know any concrete details about who's

00:11:25.200 --> 00:11:28.079
currently working on it. I can't recollect any details on

00:11:28.080 --> 00:11:29.439
who's currently working on what.

00:11:29.440 --> 00:11:35.279
Okay. And that leaves us with the last question of the day.

NOTE Q: Is there a best practice on what Org to use when following emacs-latest?

00:11:35.280 --> 00:11:38.159
I'm a bit confused about what version of Org that I should

00:11:38.160 --> 00:11:40.919
write towards because there's Org in Emacs, the one that

00:11:40.920 --> 00:11:44.279
ships built-in. There's the one in ELPA. There's the one in

00:11:44.280 --> 00:11:48.519
Org, probably the Org ELPA, I assume. Is there a best

00:11:48.520 --> 00:11:51.959
practice on what Org to use when following Emacs latest?

00:11:51.960 --> 00:11:58.919
when following us latest. It depends on, I think, my rough

00:11:58.920 --> 00:12:02.559
heuristic is if you do use Org a lot and if you follow the

00:12:02.560 --> 00:12:06.279
newest features, then use the version on Elpa, because the

00:12:06.280 --> 00:12:09.959
Elpa version should be the most up-to-date one. The Org Elpa

00:12:09.960 --> 00:12:14.999
was deprecated, to my knowledge. If that seems true, please

00:12:15.000 --> 00:12:18.319
someone interrupt me before I make a fool of myself.

00:12:18.320 --> 00:12:24.519
No one's done that yet.

00:12:24.520 --> 00:12:29.519
I think a couple of years ago there were chats and then we

00:12:29.520 --> 00:12:33.999
deprecated the all contrib ELPA, but I think all the ELPA is

00:12:34.000 --> 00:12:40.759
still alive. I didn't know that about that. Okay, in that

00:12:40.760 --> 00:12:44.839
case, that relativizes how absolute my answer is.

00:12:44.840 --> 00:12:49.559
Personally, I just use the version in Emacs, which is

00:12:49.560 --> 00:12:53.399
bundled with Emacs, which is regularly updated on master

00:12:53.400 --> 00:12:58.319
whenever there's a release. But that might take maybe, it

00:12:58.320 --> 00:13:03.559
might be a short time behind the ELPA version, or the other

00:13:03.560 --> 00:13:11.879
ELPA, the Org ELPA, which we mentioned. But I'm a very light

00:13:11.880 --> 00:13:16.119
Org mode user, so please don't take my word for that one. No,

00:13:16.120 --> 00:13:23.439
and I'm happy to come to you. Yeah. I

00:13:23.440 --> 00:13:27.719
feel like we lost Leo again. OK. Well, that's all right. I

00:13:27.720 --> 00:13:31.279
wanted a bite at that, Apple. I'm a little bit. Yeah, I also

00:13:31.280 --> 00:13:34.239
describe myself as a light org user, but somehow your

00:13:34.240 --> 00:13:37.159
comment made me think, well, maybe I do use it just a little

00:13:37.160 --> 00:13:41.719
bit more than you, Philip.

00:13:41.720 --> 00:13:45.359
From my standpoint, I'm using it as a technical basis for

00:13:45.360 --> 00:13:49.959
dungeon mode in order to keep the game notes for the games

00:13:49.960 --> 00:13:52.479
that are made using this game engine I'm making that I talked

00:13:52.480 --> 00:13:56.079
about a few years ago. As soon as you said technical grounds,

00:13:56.080 --> 00:13:59.319
you definitely use it more. Right, right. So I've studied

00:13:59.320 --> 00:14:04.159
its internals a bit, and I have my own thoughts about this or

00:14:04.160 --> 00:14:06.959
that. But of course, I'm rolling with the punches because

00:14:06.960 --> 00:14:10.119
I'm just grateful that the bear dances. What an amazing

00:14:10.120 --> 00:14:14.519
thing is Org Mode. But Leo knows far more than me,

00:14:14.520 --> 00:14:18.359
conveniently having his stage right here, so he can't

00:14:18.360 --> 00:14:22.359
defend himself from this. But I've had thoughts around this

00:14:22.360 --> 00:14:28.559
space. Are you back, Leo? Yeah, sorry, I'm back. You save us

00:14:28.560 --> 00:14:33.479
all. Maybe closing remarks. I was trying to clear my throat

00:14:33.480 --> 00:14:36.079
to be very inconspicuous about me coming back, but

00:14:36.080 --> 00:14:39.319
apparently I was ousted. Yeah, I was trying to answer the

00:14:39.320 --> 00:14:42.239
question and I was trying to desperately save you from

00:14:42.240 --> 00:14:45.999
answering, Philip, because yes, the thing about Org Mode is

00:14:46.000 --> 00:14:48.879
that if you are the kind of people who tend to check out master

00:14:48.880 --> 00:14:51.919
on Org Mode, generally it's roughly pretty stable. Like

00:14:51.920 --> 00:14:54.319
when we were working with Org Element and stuff like this,

00:14:54.320 --> 00:14:56.479
Perhaps there were some elements of stability which

00:14:56.480 --> 00:14:59.199
weren't there quite yet, but usually now it's pretty

00:14:59.200 --> 00:15:02.039
stable. So I think that if you are really excited about

00:15:02.040 --> 00:15:04.639
contributing to Org Mode and stuff like this, I think there

00:15:04.640 --> 00:15:08.199
isn't all that many risks to just checking out Org Mode

00:15:08.200 --> 00:15:10.999
Master, so cloning the repository and just keeping up to

00:15:11.000 --> 00:15:15.119
date. Otherwise, ELPA is a fairly safe bet if you want to have

00:15:15.120 --> 00:15:19.839
the latest stable version. And we've got a question about

00:15:19.840 --> 00:15:24.759
[??] as with Emacs itself. You can follow whatever is

00:15:24.760 --> 00:15:28.519
published in your package archives or in your system

00:15:28.520 --> 00:15:32.399
distribution package manager. You can build it yourself if

00:15:32.400 --> 00:15:36.839
you want to contribute and fix bugs, add features, and so on.

00:15:36.840 --> 00:15:40.399
Yeah, and I don't think perhaps a little more with Emacs,

00:15:40.400 --> 00:15:43.439
because the features that tends to get introduced in Emacs

00:15:43.440 --> 00:15:48.039
are slightly more wild. Not wild in the sense that they are

00:15:48.040 --> 00:15:50.679
less stable, but wild in the sense that they tend to change a

00:15:50.680 --> 00:15:54.119
lot more stuff. The core of Org, at least during Bastien's

00:15:54.120 --> 00:15:56.879
maintenance ship, was very stable when you think about it.

00:15:56.880 --> 00:15:59.719
So things might change with Ihor right now in terms of how he

00:15:59.720 --> 00:16:02.839
wants to change some of the core behaviors, but it's usually

00:16:02.840 --> 00:16:06.079
pretty stable. And whether you use the latest major

00:16:06.080 --> 00:16:09.159
version, the latest minor version, things are probably

00:16:09.160 --> 00:16:11.679
going to be pretty stable. It's like you heard me while you

00:16:11.680 --> 00:16:16.199
were offline. And I do agree with that, in case you might have

00:16:16.200 --> 00:16:18.319
heard both our remarks and think we're talking different

00:16:18.320 --> 00:16:22.439
angles. Actually, I think we would tend to agree on this, Leo

00:16:22.440 --> 00:16:26.759
and I. For the record, when I'm saying, oh, I have to go keep up

00:16:26.760 --> 00:16:30.719
with org, that's because org grows behaviors that I've got

00:16:30.720 --> 00:16:34.639
my own. I had to figure out at some point my own way to do it, and

00:16:34.640 --> 00:16:38.119
now I'm learning how it's done, right? So I'm like, in my

00:16:38.120 --> 00:16:41.279
abstraction, blah, right? And those conversations

00:16:41.280 --> 00:16:44.279
usually end at, and somebody else took the time to figure out

00:16:44.280 --> 00:16:48.039
how to actually make Emacs do that. Go be quiet. And I do, and I

00:16:48.040 --> 00:16:52.999
do consider that under Bastien's tenure, it has been quite

00:16:53.000 --> 00:16:57.039
stable. We might notice the occasional like, oh, this

00:16:57.040 --> 00:17:00.519
highlights now and that didn't, right? But very often, very

00:17:00.520 --> 00:17:03.599
infrequently is it breaking my workflow as a user, any of it.

00:17:03.600 --> 00:17:07.799
It's interesting to me that this mirrors my experience with

00:17:07.800 --> 00:17:12.679
Emacs itself, where I think, in my perception, Emacs master

00:17:12.680 --> 00:17:17.199
is very stable and I might notice the slight changes between

00:17:17.200 --> 00:17:21.839
git pulls. But otherwise, in my experience, Org mode

00:17:21.840 --> 00:17:24.879
suddenly changes something, I don't know what changed or

00:17:24.880 --> 00:17:29.439
what's going on or what caused it, and it seemed... I

00:17:29.440 --> 00:17:33.719
perceive it as being a sudden uncontrolled change or

00:17:33.720 --> 00:17:36.239
something. I think that's apt. Right. That gets

00:17:36.240 --> 00:17:40.159
right at it. If we're following, if we're pulling for more

00:17:40.160 --> 00:17:42.759
pretty regularly, cronjob every night or pulling a few

00:17:42.760 --> 00:17:44.639
times a day or something like that, we're going to the

00:17:44.640 --> 00:17:48.639
internals yeah, we'll have a different experience than,

00:17:48.640 --> 00:17:51.959
you know, if we only remember to update Org once every four

00:17:51.960 --> 00:17:54.759
months. It really pays to stick with everything. And

00:17:54.760 --> 00:17:59.199
suddenly lots of things might change. Whatever broke in my

00:17:59.200 --> 00:18:03.439
own config, right? And so a lot of, like a lot of things within

00:18:03.440 --> 00:18:06.759
Emacs, but also within the free software tool chain, it's

00:18:06.760 --> 00:18:09.559
how much you're going to invent in the config, invest in the

00:18:09.560 --> 00:18:14.199
config, might limit you know, and maintaining your config

00:18:14.200 --> 00:18:17.199
may limit the depth of how far it makes sense for you to go with

00:18:17.200 --> 00:18:21.759
the tool at any given point in time. Actually just looked up

00:18:21.760 --> 00:18:25.279
my org config and it's four, I said four options, user

00:18:25.280 --> 00:18:29.239
options. So that's, if that's the measurements of org

00:18:29.240 --> 00:18:32.119
expertise, that's my level, it's four.

00:18:32.120 --> 00:18:38.559
That's all good then. Four of four, I'm assuming that is,

00:18:38.560 --> 00:18:44.279
right? Four of what? What was the metric there, four of like a

00:18:44.280 --> 00:18:48.119
thousand? Four out of the number of user options that Word

00:18:48.120 --> 00:18:54.239
provides. Oh, okay, I see. Four, yeah, more like 10,000. I'm

00:18:54.240 --> 00:18:59.079
there. Yeah. All right. On that note, I suggest we move to

00:18:59.080 --> 00:19:00.999
what's close because it's fairly late for me and I need to

00:19:01.000 --> 00:19:03.119
sleep. And Philip, I think it's pretty late for you as well,

00:19:03.120 --> 00:19:07.239
isn't it? I'm in Germany, so it's about... So it is pretty

00:19:07.240 --> 00:19:09.799
late. It's the same time zone as me. It's 11 p.m. for you.

00:19:09.800 --> 00:19:16.399
Truly, yeah. Yeah, so I suggest we both take the chance to go

00:19:16.400 --> 00:19:20.359
to bed as soon as we can. But Philip, thank you so much for

00:19:20.360 --> 00:19:22.759
both the presentation and also the answers that you

00:19:22.760 --> 00:19:26.119
provided to us and the nice little chat we had at the end. We

00:19:26.120 --> 00:19:29.519
look forward to seeing you again next year, perhaps for

00:19:29.520 --> 00:19:34.159
Emacs 31. I'm not sure. I was chatting with wasamasa

00:19:34.160 --> 00:19:37.679
trying to make prognostics about when Emacs 30 is going to be

00:19:37.680 --> 00:19:40.839
released. There's a pre-release coming soon. I should have

00:19:40.840 --> 00:19:46.719
mentioned that earlier. Well, there you go. Gone.

00:19:46.720 --> 00:19:51.839
All right. Well, thank you so much, Philip. We'll be moving

00:19:51.840 --> 00:19:54.479
towards close. Give us about two minutes to get set up in the

00:19:54.480 --> 00:19:58.439
other room. And Philip, we'll see you next time. Goodbye.

00:19:58.440 --> 00:20:02.160
Bye-bye. Thank you.