path: root/2020/subtitles/emacsconf-2020--38-emacs-development-update--john-wiegley.vtt

WEBVTT

00:00:00.080 --> 00:00:03.040
Hello EmacsConf! This is John Wiegley, I'm

00:00:03.040 --> 00:00:04.960
one of the co-maintainers of Emacs along

00:00:04.960 --> 00:00:06.319
with Eli Zaretskii

00:00:06.319 --> 00:00:09.280
and Lars Ingebrigtsen, and I wanted to

00:00:09.280 --> 00:00:09.840
give you

00:00:09.840 --> 00:00:12.639
a technical update on what has been

00:00:12.639 --> 00:00:14.960
happening

00:00:14.960 --> 00:00:17.573
with the Emacs in the last year.

00:00:17.573 --> 00:00:20.640
So, specifically we have a few notes that

00:00:20.640 --> 00:00:21.600
I've gotten from

00:00:21.600 --> 00:00:24.480
a call with Eli, he's been in charge of

00:00:24.480 --> 00:00:25.840
directing most of the

00:00:25.840 --> 00:00:28.000
technical contributions on the mailing

00:00:28.000 --> 00:00:30.160
list and monitoring all the patches.

00:00:30.160 --> 00:00:33.200
So, I'm more here just as a messenger.

00:00:33.200 --> 00:00:35.840
He says that we have good progress and

00:00:35.840 --> 00:00:37.120
support for Cairo,

00:00:37.120 --> 00:00:39.040
this is going to be enabled by default

00:00:39.040 --> 00:00:40.320
in Emacs 28,

00:00:40.320 --> 00:00:42.480
and Cairo plus HarfBuzz is going to be

00:00:42.480 --> 00:00:44.800
the preferred rendering combination.

00:00:44.800 --> 00:00:46.879
So, Cairo support is not new, but in the

00:00:46.879 --> 00:00:48.719
past there were a lot of bugs in the

00:00:48.719 --> 00:00:51.440
code, and so it was made experimental.

00:00:51.440 --> 00:00:52.960
Most of those bugs have been fixed

00:00:52.960 --> 00:00:54.960
recently, and now it becomes the default

00:00:54.960 --> 00:00:56.320
in the next major version,

00:00:56.320 --> 00:00:58.320
which will enable several good features

00:00:58.320 --> 00:01:00.320
such as color emojis, if you're looking

00:01:00.320 --> 00:01:01.680
forward to those.

00:01:01.680 --> 00:01:04.720
Xft, as a result is deprecated. There are

00:01:04.720 --> 00:01:06.560
bugs not getting fixed in that code, it

00:01:06.560 --> 00:01:07.760
doesn't appear to be very well

00:01:07.760 --> 00:01:08.720
maintained.

00:01:08.720 --> 00:01:10.960
It was the most advanced font backend

00:01:10.960 --> 00:01:13.760
in Emacs before Cairo became dependable.

00:01:13.760 --> 00:01:15.920
So, now that we have a more a better

00:01:15.920 --> 00:01:17.840
maintained and available solution in

00:01:17.840 --> 00:01:19.360
Cairo, we're going to go from that,

00:01:19.360 --> 00:01:21.839
go from Xft to that.

00:01:21.839 --> 00:01:23.840
Native compilation in Lisp

00:01:23.840 --> 00:01:26.400
will also be landing soon. It's currently

00:01:26.400 --> 00:01:28.080
on a branch, but there are several people

00:01:28.080 --> 00:01:28.799
using it,

00:01:28.799 --> 00:01:31.040
they say, they're very impressed. It does

00:01:31.040 --> 00:01:32.479
require live GCC

00:01:32.479 --> 00:01:35.600
JIT to be installed for it to work, and

00:01:35.600 --> 00:01:37.439
this means you have to have GCC 10

00:01:37.439 --> 00:01:38.960
installed.

00:01:38.960 --> 00:01:41.040
Execution of Emacs Lisp with native

00:01:41.040 --> 00:01:42.240
compilation on

00:01:42.240 --> 00:01:45.280
is about 2.5 times faster than the

00:01:45.280 --> 00:01:46.159
bytecode

00:01:46.159 --> 00:01:48.399
interpreter, we don't yet have any

00:01:48.399 --> 00:01:49.439
measurements on

00:01:49.439 --> 00:01:51.600
memory or how it affects resources

00:01:51.600 --> 00:01:52.960
besides CPU, so,

00:01:52.960 --> 00:01:54.720
we do look forward to having more

00:01:54.720 --> 00:01:56.399
numbers and analysis to see what the

00:01:56.399 --> 00:01:58.320
real impact of that is going to be,

00:01:58.320 --> 00:02:01.360
also, it may vary in compute advantage

00:02:01.360 --> 00:02:02.799
based on the type of workload that

00:02:02.799 --> 00:02:04.320
you're performing.

00:02:04.320 --> 00:02:06.240
A downside to the native compilation at

00:02:06.240 --> 00:02:08.080
the moment is that, it takes a long

00:02:08.080 --> 00:02:10.720
time to compile even when you're doing a

00:02:10.720 --> 00:02:12.720
16 core build of Emacs,

00:02:12.720 --> 00:02:14.959
it can still take 15 minutes to compile

00:02:14.959 --> 00:02:15.760
Emacs

00:02:15.760 --> 00:02:17.840
and all of its Lisp code

00:02:17.840 --> 00:02:19.520
with this enabled.

00:02:19.520 --> 00:02:21.840
Also, this is going to have to happen on

00:02:21.840 --> 00:02:23.120
every user's machine

00:02:23.120 --> 00:02:25.360
because we cannot distribute the native

00:02:25.360 --> 00:02:27.520
compilation products, they are specific

00:02:27.520 --> 00:02:29.760
to the processor that you might be

00:02:29.760 --> 00:02:30.806
running on.

00:02:30.806 --> 00:02:33.920
So, the Emacs distribution will remain much

00:02:33.920 --> 00:02:35.680
as it is now, but if you want to have the

00:02:35.680 --> 00:02:37.760
benefits of natively compiled

00:02:37.760 --> 00:02:39.599
core Lisp files, you're going to have to

00:02:39.599 --> 00:02:41.519
spend that time and have GCC 10

00:02:41.519 --> 00:02:42.400
available

00:02:42.400 --> 00:02:45.840
to get that compilation support.

00:02:45.840 --> 00:02:48.959
The GTK only build is being prepared

00:02:48.959 --> 00:02:52.160
for merging. What this does is, it

00:02:52.160 --> 00:02:52.959
throws away

00:02:52.959 --> 00:02:55.120
most of the other tool kits that Emacs

00:02:55.120 --> 00:02:56.000
was using

00:02:56.000 --> 00:02:59.280
and relies only on GTK, making Emacs

00:02:59.280 --> 00:03:01.760
much more of a GTK application than it

00:03:01.760 --> 00:03:03.920
has been.

00:03:03.920 --> 00:03:06.480
The main issue here is that we were

00:03:06.480 --> 00:03:08.480
abusing GTK in some ways that weren't

00:03:08.480 --> 00:03:09.360
really meant,

00:03:09.360 --> 00:03:10.879
and now we're going to be more of a

00:03:10.879 --> 00:03:12.879
first club…, GTK will be more of a first

00:03:12.879 --> 00:03:14.080
class citizen in the

00:03:14.080 --> 00:03:17.440
approach and the ways that we use it, and

00:03:17.440 --> 00:03:19.280
be using it in the ways that the GTK

00:03:19.280 --> 00:03:21.200
developers intended.

00:03:21.200 --> 00:03:23.360
There is going to be much more support

00:03:23.360 --> 00:03:24.640
for xt-mouse.

00:03:24.640 --> 00:03:27.280
So, xt-mouse allows you to use your mouse

00:03:27.280 --> 00:03:29.120
inside of a terminal window,

00:03:29.120 --> 00:03:30.799
which you could do before, but there were

00:03:30.799 --> 00:03:33.120
certain aspects such as menus

00:03:33.120 --> 00:03:36.159
that weren't supported. So, instead of

00:03:36.159 --> 00:03:38.239
having kind of partial support for mouse

00:03:38.239 --> 00:03:40.473
inside of an XTerm, with xt-mouse,

00:03:40.473 --> 00:03:42.879
you get full support. This is going

00:03:42.879 --> 00:03:44.959
to allow

00:03:44.959 --> 00:03:46.720
changes in the way that things can be

00:03:46.720 --> 00:03:48.159
bound, the ways that

00:03:48.159 --> 00:03:51.200
key bindings can…, the mouse events can

00:03:51.200 --> 00:03:53.200
be mapped to key bindings while in

00:03:53.200 --> 00:03:56.879
XTerms, and yeah, little by little

00:03:56.879 --> 00:03:58.480
this support is being extended even

00:03:58.480 --> 00:03:59.040
further,

00:03:59.040 --> 00:04:01.599
so we look forward to seeing that

00:04:01.599 --> 00:04:04.080
develop in the near term.

00:04:04.080 --> 00:04:06.239
Once this is merged by the way, also then

00:04:06.239 --> 00:04:08.080
Emacs will have mouse support in every

00:04:08.080 --> 00:04:09.840
one of its available configurations,

00:04:09.840 --> 00:04:12.173
which has not been true until now.

00:04:12.173 --> 00:04:14.680
Emacs 27 will be soon releasing

00:04:14.680 --> 00:04:17.519
27.2, and the pretest for that should

00:04:17.519 --> 00:04:19.919
begin sometime soon after EmacsConf is

00:04:19.919 --> 00:04:20.880
done.

00:04:20.880 --> 00:04:23.360
And finally Emacs 28 is going to get

00:04:23.360 --> 00:04:24.800
better emoji support,

00:04:24.800 --> 00:04:26.479
right now emojis are registered

00:04:26.479 --> 00:04:29.120
internally within Emacs as symbols

00:04:29.120 --> 00:04:31.759
which works in some ways but does not

00:04:31.759 --> 00:04:33.759
support some of the special features

00:04:33.759 --> 00:04:37.360
of emojis such as different

00:04:37.360 --> 00:04:40.000
skin tones for the hand emoji or face

00:04:40.000 --> 00:04:41.120
emojis.

00:04:41.120 --> 00:04:43.280
In Emacs 28, emojis are going to have

00:04:43.280 --> 00:04:45.199
their own support within the

00:04:45.199 --> 00:04:47.199
C code, and then this is going to allow

00:04:47.199 --> 00:04:49.360
those types of variations and other

00:04:49.360 --> 00:04:51.439
emoji specific font setups.

00:04:51.439 --> 00:04:54.639
So, that is everything for Emacs

00:04:54.639 --> 00:04:56.720
in the future, I don't have a timeline

00:04:56.720 --> 00:04:59.120
for you on when 28 will be available,

00:04:59.120 --> 00:05:01.520
but 27 is going to keep improving until

00:05:01.520 --> 00:05:02.720
we're ready to get there.

00:05:02.720 --> 00:05:04.906
So, have fun with the rest of EmacsConf,

00:05:04.906 --> 00:05:06.479
and I hope to see you there,

00:05:06.479 --> 00:05:09.199
Bye.