1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
# Emacs development update
John Wiegley
[[!template id=vid src="https://mirror.csclub.uwaterloo.ca/emacsconf/2020/emacsconf-2020--38-emacs-development-update--john-wiegley.webm" size="75M" subtitles="/2020/subtitles/emacsconf-2020--38-emacs-development-update--john-wiegley.vtt" duration="5:07"]]
[Download compressed .webm video (8.4M)](https://mirror.csclub.uwaterloo.ca/emacsconf/2020/smaller/emacsconf-2020--38-emacs-development-update--john-wiegley--vp9-q56-video-original-audio.webm)
[View transcript](#transcript)
- Actual start and end time (EST): Start 2020-11-29T09.12.40; End:
2020-11-29T09.17.51
# Questions
## There is xwidget webkit based browser built in Emacs but this is not trivial to install it, it is slow and many pages do not work at all. On the other hand, there are standalone Emacs like browsers e.g. "Nyxt" and "Qutebrowser" (This one I use and love, in theory this is Vim like browser but can be configured to be Emacs like). Having built in high performance browser (not dependent on EXWM) would be game changing feature for Emacs. Are there any plans to make such browser within the roadmap of Emacs development or maybe that would make sense to work together with either Nyxt or Qutebrowser communities to integrate their browsers natively in Emacs?
## (karthink on IRC): Can't native compilation happen asynchronously after installing Emacs? (Including for files in site-lisp)
# Notes
- Cairo enabled by default in Emacs 28.
- Cairo-URL: <https://www.cairographics.org/>
- Native compilation will land soon (currently in another branch,
needs libgccjit). About 2.5 times faster(?)
- Downtime of native compilation: long time to compile Emacs.
- Native compilation products specific to the machines.
- Emacs 27.2 will be released soon.
- Emacs 28 will have better emoji support 🎉 (within C code). No
timeline for 28 currently.
<!-- transcript: 2020/subtitles/emacsconf-2020--38-emacs-development-update--john-wiegley.vtt -->
<a name="transcript"></a>
# Transcript
Hello EmacsConf! This is John Wiegley, I'm one of the co-maintainers
of Emacs along with Eli Zaretskii and Lars Ingebrigtsen, and I wanted
to give you a technical update on what has been happening with the
Emacs in the last year. So, specifically we have a few notes that
I've gotten from a call with Eli, he's been in charge of directing
most of the technical contributions on the mailing list and monitoring
all the patches. So, I'm more here just as a messenger.
(00:33) He says that we have good progress and support for Cairo, this
is going to be enabled by default in Emacs 28, and Cairo plus HarfBuzz
is going to be the preferred rendering combination. So, Cairo support
is not new, but in the past there were a lot of bugs in the code, and
so it was made experimental. Most of those bugs have been fixed
recently, and now it becomes the default in the next major version,
which will enable several good features such as color emojis, if
you're looking forward to those. Xft, as a result is deprecated. There
are bugs not getting fixed in that code, it doesn't appear to be very
well maintained. It was the most advanced font backend in Emacs before
Cairo became dependable. So, now that we have a more a better
maintained and available solution in Cairo, we're going to go from
that, go from Xft to that.
(01:21) Native compilation in Lisp will also be landing soon. It's
currently on a branch, but there are several people using it, they
say, they're very impressed. It does require live GCC JIT to be
installed for it to work, and this means you have to have GCC 10
installed. Execution of Emacs Lisp with native compilation on is about
2.5 times faster than the bytecode interpreter, we don't yet have any
measurements on memory or how it affects resources besides CPU, so, we
do look forward to having more numbers and analysis to see what the
real impact of that is going to be, also, it may vary in compute
advantage based on the type of workload that you're performing. A
downside to the native compilation at the moment is that, it takes a
long time to compile even when you're doing a 16 core build of Emacs,
it can still take 15 minutes to compile Emacs and all of its Lisp code
with this enabled. Also, this is going to have to happen on every
user's machine because we cannot distribute the native compilation
products, they are specific to the processor that you might be running
on. So, the Emacs distribution will remain much as it is now, but if
you want to have the benefits of natively compiled core Lisp files,
you're going to have to spend that time and have GCC 10 available to
get that compilation support.
(02:45) The GTK only build is being prepared for merging. What this
does is, it throws away most of the other tool kits that Emacs was
using and relies only on GTK, making Emacs much more of a GTK
application than it has been. The main issue here is that we were
abusing GTK in some ways that weren't really meant, and now we're
going to be more of a first club…, GTK will be more of a first class
citizen in the approach and the ways that we use it, and be using it
in the ways that the GTK developers intended.
(03:21) There is going to be much more support for xt-mouse. So,
xt-mouse allows you to use your mouse inside of a terminal window,
which you could do before, but there were certain aspects such as
menus that weren't supported. So, instead of having kind of partial
support for mouse inside of an XTerm, with xt-mouse, you get full
support. This is going to allow changes in the way that things can be
bound, the ways that key bindings can…, the mouse events can be mapped
to key bindings while in XTerms, and yeah, little by little this
support is being extended even further, so we look forward to seeing
that develop in the near term. Once this is merged by the way, also
then Emacs will have mouse support in every one of its available
configurations, which has not been true until now.
(04:12) Emacs 27 will be soon releasing 27.2, and the pretest for that
should begin sometime soon after EmacsConf is done.
(04:20) And finally Emacs 28 is going to get better emoji support,
right now emojis are registered internally within Emacs as symbols
which works in some ways but does not support some of the special
features of emojis such as different skin tones for the hand emoji or
face emojis. In Emacs 28, emojis are going to have their own support
within the C code, and then this is going to allow those types of
variations and other emoji specific font setups.
(04:51) So, that is everything for Emacs in the future, I don't have a
timeline for you on when 28 will be available, but 27 is going to keep
improving until we're ready to get there. So, have fun with the rest
of EmacsConf, and I hope to see you there, Bye.
<!-- /transcript -->
|
