0:00:01.520,0:00:07.200
hello everyone my name is toniang
0:00:04.400,0:00:09.280
I've been using amax for about 10 years
0:00:07.200,0:00:11.519
today I'm going to talk about 360
0:00:09.280,0:00:13.759
a new imax package that allows ems to
0:00:11.519,0:00:17.840
pass multiple programming languages
0:00:13.759,0:00:21.840
in real time
0:00:17.840,0:00:23.359
so what is the problem statement
0:00:21.840,0:00:24.960
in order to support programming
0:00:23.359,0:00:25.760
functionalities for a particular
0:00:24.960,0:00:27.680
language
0:00:25.760,0:00:29.679
a text editor needs to have some degree
0:00:27.680,0:00:31.840
of language understanding
0:00:29.679,0:00:33.840
traditionally text editors have relied
0:00:31.840,0:00:34.960
very heavily on regular expressions for
0:00:33.840,0:00:38.320
this
0:00:34.960,0:00:39.280
e-max is no different most language
0:00:38.320,0:00:40.879
major modes use
0:00:39.280,0:00:42.960
regular expressions for syntax
0:00:40.879,0:00:46.239
highlighting code navigation
0:00:42.960,0:00:47.440
folding indexing and so on regular
0:00:46.239,0:00:50.559
expressions are
0:00:47.440,0:00:53.600
problematic for a couple of reasons
0:00:50.559,0:00:54.000
they're slow and inaccurate they also
0:00:53.600,0:00:56.800
make
0:00:54.000,0:00:57.440
the code hard to read and write
0:00:56.800,0:00:59.199
sometimes
0:00:57.440,0:01:01.199
it's because the regular expressions
0:00:59.199,0:01:04.000
themselves are very hairy
0:01:01.199,0:01:05.199
and sometimes because they are just not
0:01:04.000,0:01:07.840
powerful enough
0:01:05.199,0:01:11.200
some helper code is usually needed to
0:01:07.840,0:01:13.280
pass more intricate language features
0:01:11.200,0:01:16.159
that also illustrates the core problem
0:01:13.280,0:01:18.400
with regular expressions
0:01:16.159,0:01:21.119
in that they are not powerful enough to
0:01:18.400,0:01:22.640
pass programming languages
0:01:21.119,0:01:25.040
an example feature that regular
0:01:22.640,0:01:27.520
expressions cannot handle very well
0:01:25.040,0:01:28.320
is string interpolation which is a very
0:01:27.520,0:01:31.680
common feature
0:01:28.320,0:01:34.079
in many modern programming languages
0:01:31.680,0:01:35.840
it would be much nicer if image somehow
0:01:34.079,0:01:36.479
had structural understanding of source
0:01:35.840,0:01:39.439
code
0:01:36.479,0:01:39.439
like ides do
0:01:39.520,0:01:42.960
there have been multiple efforts to
0:01:41.119,0:01:45.280
bring this kind of programming language
0:01:42.960,0:01:47.119
understanding into Emacs
0:01:45.280,0:01:48.640
there are language specific persons
0:01:47.119,0:01:50.240
written in elise
0:01:48.640,0:01:52.320
they can be thought of as the next
0:01:50.240,0:01:54.960
logical step of the glue code on top
0:01:52.320,0:01:56.000
of tribal expressions moving from
0:01:54.960,0:01:58.079
partial local
0:01:56.000,0:01:59.840
pattern recognition into a full-fledged
0:01:58.079,0:02:01.439
parser
0:01:59.840,0:02:03.040
the most prominent example of this
0:02:01.439,0:02:06.159
approach is probably the famous
0:02:03.040,0:02:06.159
js2 mode
0:02:06.479,0:02:12.959
however this approach has several issues
0:02:10.080,0:02:13.680
parsing is computationally expensive and
0:02:12.959,0:02:16.800
imagine
0:02:13.680,0:02:18.400
is not good at that kind of stuff
0:02:16.800,0:02:20.840
furthermore maintenance is very
0:02:18.400,0:02:22.160
troublesome in order to work on these
0:02:20.840,0:02:23.599
process
0:02:22.160,0:02:25.599
first you have to know at least well
0:02:23.599,0:02:27.760
enough and then you have to be
0:02:25.599,0:02:30.319
comfortable with writing a
0:02:27.760,0:02:32.080
recursive ascendant parser while
0:02:30.319,0:02:34.000
constantly keeping up with changes to
0:02:32.080,0:02:36.879
the language itself
0:02:34.000,0:02:39.360
which can be evolving very quickly like
0:02:36.879,0:02:41.599
javascript for example
0:02:39.360,0:02:45.680
together these constraints significantly
0:02:41.599,0:02:47.760
reduce the pull of potential maintenance
0:02:45.680,0:02:49.680
the biggest issue though in my opinion
0:02:47.760,0:02:52.879
is lack of the set of generic
0:02:49.680,0:02:54.319
and reusable apis this makes them very
0:02:52.879,0:02:55.920
hard to use
0:02:54.319,0:02:57.920
for minor modes that want to deal with
0:02:55.920,0:02:59.920
cross-cutting concerns across multiple
0:02:57.920,0:03:01.760
languages
0:02:59.920,0:03:03.599
the other approach which has been
0:03:01.760,0:03:04.319
gaining a lot of momentum in recent
0:03:03.599,0:03:06.560
years
0:03:04.319,0:03:08.159
is externalizing language understanding
0:03:06.560,0:03:12.239
to another process
0:03:08.159,0:03:14.480
also known as language server protocol
0:03:12.239,0:03:16.560
this second approach is actually a very
0:03:14.480,0:03:18.400
interesting one
0:03:16.560,0:03:21.280
my decoupling language understanding
0:03:18.400,0:03:23.760
from the editing facility itself
0:03:21.280,0:03:25.120
the usb servers can attract a lot more
0:03:23.760,0:03:28.959
contributors
0:03:25.120,0:03:32.400
which makes maintenance easier however
0:03:28.959,0:03:34.720
they also have several issues available
0:03:32.400,0:03:36.000
being a separate process they are
0:03:34.720,0:03:39.920
usually more resource
0:03:36.000,0:03:42.159
intensive and depending on the language
0:03:39.920,0:03:44.640
the usb server itself can bring with it
0:03:42.159,0:03:47.680
a host of additional dependencies
0:03:44.640,0:03:50.560
external to Emacs which may message to
0:03:47.680,0:03:50.560
install and manage
0:03:50.640,0:03:55.120
furthermore json over rpc has pretty
0:03:53.760,0:03:57.840
high latency
0:03:55.120,0:04:00.879
for one-off tasks like jumping to source
0:03:57.840,0:04:03.040
or on-demand completion is great
0:04:00.879,0:04:06.000
but for things like code highlighting
0:04:03.040,0:04:08.319
the latency is just too much
0:04:06.000,0:04:10.480
I was using rust and I was following the
0:04:08.319,0:04:11.760
community effort to improve its id
0:04:10.480,0:04:13.680
support
0:04:11.760,0:04:15.760
hoping to integrate some of that into
0:04:13.680,0:04:17.600
Emacs itself
0:04:15.760,0:04:19.759
then I heard someone from community
0:04:17.600,0:04:23.280
mention tree sitter
0:04:19.759,0:04:23.280
and I decided to check it out
0:04:23.360,0:04:28.720
basically trisita is an incremental
0:04:25.520,0:04:31.000
parsing library and a parser generator
0:04:28.720,0:04:33.040
it was introduced by the item editor in
0:04:31.000,0:04:35.680
2018
0:04:33.040,0:04:36.960
besides item is also being integrated
0:04:35.680,0:04:41.040
into the neo-vim
0:04:36.960,0:04:42.479
editor and github is using it to power
0:04:41.040,0:04:45.600
their source code analysis and
0:04:42.479,0:04:45.600
navigation features
0:04:45.840,0:04:49.199
it is written in c and can be compiled
0:04:48.639,0:04:53.120
for all
0:04:49.199,0:04:56.080
major platforms it can even be compiled
0:04:53.120,0:04:57.600
to web assembly to run on the web that's
0:04:56.080,0:05:00.400
how github is using it
0:04:57.600,0:05:00.400
on their website
0:05:00.800,0:05:05.840
so why is trisita an interesting
0:05:02.960,0:05:07.360
solution to this problem
0:05:05.840,0:05:10.000
there are multiple features that make it
0:05:07.360,0:05:12.400
an attractive option
0:05:10.000,0:05:13.680
it is designed to be fast by being
0:05:12.400,0:05:15.680
incremental
0:05:13.680,0:05:18.160
the initial parts of a typical big fight
0:05:15.680,0:05:20.240
can take tens of milliseconds
0:05:18.160,0:05:22.560
while subsequent incremental processes
0:05:20.240,0:05:24.720
are sub milliseconds
0:05:22.560,0:05:26.240
it achieves this by using structural
0:05:24.720,0:05:29.360
sharing
0:05:26.240,0:05:32.960
meaning replacing only affected nodes
0:05:29.360,0:05:36.000
in the old tree when it needs to
0:05:32.960,0:05:37.120
also unlike lsp being in the same
0:05:36.000,0:05:40.639
process
0:05:37.120,0:05:42.880
it has much lower latency
0:05:40.639,0:05:44.960
secondly it provides a uniform
0:05:42.880,0:05:47.039
programming interface
0:05:44.960,0:05:48.720
the same data structures and functions
0:05:47.039,0:05:50.400
work on parse trees of different
0:05:48.720,0:05:52.160
languages
0:05:50.400,0:05:54.160
syntax knows of different languages
0:05:52.160,0:05:57.360
differ only by their types
0:05:54.160,0:05:58.960
and their possible child nodes this
0:05:57.360,0:06:02.000
is a big advantage over language
0:05:58.960,0:06:02.000
specific parcels
0:06:02.240,0:06:06.880
thirdly it's written in self-contained
0:06:04.880,0:06:09.680
embeddable c
0:06:06.880,0:06:10.400
as I mentioned previously it can even be
0:06:09.680,0:06:13.759
compiled
0:06:10.400,0:06:15.199
to webassembly this makes integrating it
0:06:13.759,0:06:18.240
into various editors
0:06:15.199,0:06:21.840
quite easy without having to install
0:06:18.240,0:06:21.840
any external dependencies
0:06:22.880,0:06:28.000
one thing that is not mentioned here is
0:06:24.639,0:06:31.039
that being a parcel generator
0:06:28.000,0:06:34.880
scrummers are declarative
0:06:31.039,0:06:36.720
together with being editor independent
0:06:34.880,0:06:38.160
this makes the pool of potential
0:06:36.720,0:06:42.400
contributors
0:06:38.160,0:06:45.520
much larger so I was convinced
0:06:42.400,0:06:48.000
that trisito is a good fit for Emacs
0:06:45.520,0:06:48.720
last year I started writing the bindings
0:06:48.000,0:06:50.960
using
0:06:48.720,0:06:53.280
dynamic model support introduced in imax
0:06:50.960,0:06:55.360
25.
0:06:53.280,0:06:58.479
dynamic module means there is platform
0:06:55.360,0:07:00.560
specific native code involved
0:06:58.479,0:07:02.880
but since they are pre-compiled binaries
0:07:00.560,0:07:06.319
for the three major platforms
0:07:02.880,0:07:08.319
it should work in most places currently
0:07:06.319,0:07:09.440
the core functionalities are in a pretty
0:07:08.319,0:07:12.560
good shape
0:07:09.440,0:07:14.840
syntax highlighting is working nicely
0:07:12.560,0:07:16.080
the whole thing is split into three
0:07:14.840,0:07:17.759
packages
0:07:16.080,0:07:20.319
tree sitter is the main package that
0:07:17.759,0:07:22.800
other packages should depend on
0:07:20.319,0:07:24.000
tree system lens is the language bundle
0:07:22.800,0:07:27.199
that includes support
0:07:24.000,0:07:30.080
for most common languages
0:07:27.199,0:07:32.160
and finally the core apis are in the
0:07:30.080,0:07:36.160
package tsc
0:07:32.160,0:07:38.800
which stands for trees the core
0:07:36.160,0:07:41.919
it is the implicit dependency of the
0:07:38.800,0:07:41.919
three-seater package
0:07:43.520,0:07:47.520
the main package includes the miner mode
0:07:46.000,0:07:49.840
3-seater mode
0:07:47.520,0:07:52.560
this provides the base for other major
0:07:49.840,0:07:55.280
or minor modes to build on
0:07:52.560,0:07:55.840
using image change tracking hooks it
0:07:55.280,0:07:58.080
enables
0:07:55.840,0:08:00.800
incremental parsing and provides a
0:07:58.080,0:08:04.080
syntax tree that is always up to date
0:08:00.800,0:08:06.560
after any edits in a buffer
0:08:04.080,0:08:10.080
there is also a basic debug mode that
0:08:06.560,0:08:13.360
shows the parse tree in another buffer
0:08:10.080,0:08:15.759
here is a quick demo
0:08:13.360,0:08:17.520
here I mean an empty python buffer with
0:08:15.759,0:08:19.440
three seater enabled
0:08:17.520,0:08:26.560
I'm going to turn on the debug mode to
0:08:19.440,0:08:28.720
see the parse tree
0:08:26.560,0:08:30.639
since the buffer is empty there is only
0:08:28.720,0:08:33.279
one node in the syntax tree the top
0:08:30.639,0:08:41.839
level module node
0:08:33.279,0:08:41.839
let's try typing some code
0:09:11.040,0:09:14.640
as you can see as I type into the python
0:09:13.600,0:09:19.120
buffer
0:09:14.640,0:09:21.120
the syntax tree updates in real time
0:09:19.120,0:09:23.279
the other minor mode included in the
0:09:21.120,0:09:26.640
main package is 3-seater
0:09:23.279,0:09:28.480
hl mode it overrides font-lock mode and
0:09:26.640,0:09:31.839
provides its own set of phases
0:09:28.480,0:09:32.800
and customization options it is query
0:09:31.839,0:09:35.200
driven
0:09:32.800,0:09:36.240
that means instead of regular
0:09:35.200,0:09:38.720
expressions
0:09:36.240,0:09:40.320
it uses a list like query language to
0:09:38.720,0:09:43.760
map syntax notes
0:09:40.320,0:09:45.760
to highlighting phrases I'm going to
0:09:43.760,0:09:51.839
open a python file with small snippets
0:09:45.760,0:09:51.839
that showcase syntax highlighting
0:09:54.320,0:09:59.279
so this is the default highlighting
0:09:55.920,0:09:59.279
provided by python mode
0:10:00.880,0:10:04.640
this is the highlighting enabled by tree
0:10:02.839,0:10:07.680
sitter
0:10:04.640,0:10:11.680
as you can see string interpolation
0:10:07.680,0:10:15.440
and decorators are highlighted correctly
0:10:11.680,0:10:15.440
function calls are also highlighted
0:10:17.440,0:10:21.839
you can also note that property
0:10:20.240,0:10:24.640
assessors
0:10:21.839,0:10:27.200
and property assignments are highlighted
0:10:24.640,0:10:27.200
differently
0:10:27.440,0:10:30.880
what I like the most about this is that
0:10:29.360,0:10:32.640
new bindings are consistently
0:10:30.880,0:10:36.320
highlighted
0:10:32.640,0:10:39.760
this included local variable
0:10:36.320,0:10:42.480
function parameters and property
0:10:39.760,0:10:42.480
mutations
0:10:45.760,0:10:49.279
before going through the three queries
0:10:48.000,0:10:51.680
and the syntax highlighting
0:10:49.279,0:10:53.760
customization options
0:10:51.680,0:10:55.040
let's take a brief look at the core data
0:10:53.760,0:10:58.079
structures and functions
0:10:55.040,0:10:59.839
that tree sitter provides
0:10:58.079,0:11:02.240
so parsing is done with the help of a
0:10:59.839,0:11:04.160
generic parser object
0:11:02.240,0:11:06.000
a single parser object can be used to
0:11:04.160,0:11:08.320
pass different languages
0:11:06.000,0:11:09.279
by sending different language objects to
0:11:08.320,0:11:10.880
it
0:11:09.279,0:11:14.079
the language objects themselves are
0:11:10.880,0:11:16.079
loaded from shared libraries
0:11:14.079,0:11:17.360
since three seater mode already handles
0:11:16.079,0:11:19.440
the parsing part
0:11:17.360,0:11:20.800
we will instead focus on the functions
0:11:19.440,0:11:24.720
that inspect nodes
0:11:20.800,0:11:24.720
and in the resulting path tree
0:11:25.279,0:11:43.839
we can ask tree sitter what is the
0:11:27.200,0:11:43.839
syntax node at point
0:11:44.240,0:11:48.480
uh is it an opaque object so this is not
0:11:47.200,0:11:57.839
very useful
0:11:48.480,0:11:57.839
we can instead ask what is its type
0:12:03.760,0:12:08.959
so his type is the symbol comparison
0:12:06.560,0:12:11.600
operator
0:12:08.959,0:12:13.680
trees there are two kinds of nodes
0:12:11.600,0:12:15.519
anonymous nodes and named nodes
0:12:13.680,0:12:17.040
anonymous nodes correspond to simple
0:12:15.519,0:12:19.839
grammar elements
0:12:17.040,0:12:21.279
like keywords operators punctuations and
0:12:19.839,0:12:24.160
so on
0:12:21.279,0:12:25.920
name nodes on the other hand grammar
0:12:24.160,0:12:26.639
elements that are interesting enough for
0:12:25.920,0:12:30.320
their own
0:12:26.639,0:12:31.839
to have a name like an identifier an
0:12:30.320,0:12:35.200
expression
0:12:31.839,0:12:35.200
or a function definition
0:12:35.440,0:12:41.519
name node types are symbols while
0:12:37.760,0:12:41.519
anonymous node types are strings
0:12:42.639,0:12:49.519
for example if we are on this
0:12:46.320,0:12:49.519
comparison operator
0:12:49.760,0:12:53.839
the node type should be a string
0:12:55.920,0:12:58.959
we can also get other information about
0:12:57.920,0:13:07.839
the node
0:12:58.959,0:13:07.839
for example what is this text
0:13:09.680,0:13:35.839
or where it is in the buffer
0:13:20.800,0:13:35.839
or what is its parent
0:13:43.199,0:13:46.839
there are many other apis to query or
0:13:46.160,0:13:49.839
not
0:13:46.839,0:13:49.839
properties
0:13:52.639,0:13:58.240
tree sitter allows searching for
0:13:54.399,0:14:01.440
structural patterns within a parse tree
0:13:58.240,0:14:03.519
it does so through a list like language
0:14:01.440,0:14:04.639
this language supports by the matching
0:14:03.519,0:14:07.760
by node types
0:14:04.639,0:14:10.079
field names and predicates
0:14:07.760,0:14:12.639
it also allows capturing nodes for
0:14:10.079,0:14:17.839
further processing
0:14:12.639,0:14:17.839
let's try to see some examples
0:14:37.680,0:14:43.839
so in this very simple query we just
0:14:41.040,0:14:46.399
try to highlight all the identifiers in
0:14:43.839,0:14:46.399
the buffer
0:14:49.040,0:14:53.120
this s side tells trisito to capture a
0:14:51.920,0:14:55.839
node
0:14:53.120,0:14:57.360
in the context of the query builder it's
0:14:55.839,0:15:00.320
not very important
0:14:57.360,0:15:01.760
but in normal highlighting query this
0:15:00.320,0:15:05.920
will determine
0:15:01.760,0:15:05.920
the face used to highlight the note
0:15:06.639,0:15:10.320
suppose we want to capture all the
0:15:08.800,0:15:13.519
function names
0:15:10.320,0:15:27.839
instead of just any identifier
0:15:13.519,0:15:27.839
you can improve the query like this
0:15:29.440,0:15:32.639
uh this will highlight the whole
0:15:31.600,0:15:35.519
definition
0:15:32.639,0:15:36.399
but we only want to capture the function
0:15:35.519,0:15:39.600
name
0:15:36.399,0:15:42.800
which means the identifier
0:15:39.600,0:15:46.320
here so we
0:15:42.800,0:15:48.639
move the capture to after the identifier
0:15:46.320,0:15:48.639
node
0:15:49.600,0:15:52.959
if we want to capture the class names as
0:15:51.759,0:16:09.839
well
0:15:52.959,0:16:09.839
we just add another pattern
0:16:10.079,0:16:14.399
let's look at a more practical example
0:16:20.320,0:16:23.759
here we can see that single quotes
0:16:22.959,0:16:25.600
strings and
0:16:23.759,0:16:27.279
double quotes screens are highlighted
0:16:25.600,0:16:30.399
the same
0:16:27.279,0:16:33.440
but in some places
0:16:30.399,0:16:35.440
because of some coding conventions
0:16:33.440,0:16:37.279
it may be desirable to highlight them
0:16:35.440,0:16:39.680
differently for example if
0:16:37.279,0:16:40.880
the string is single quoted we may want
0:16:39.680,0:16:43.759
to highlight it
0:16:40.880,0:16:43.759
as a constant
0:16:44.399,0:16:47.600
let's try to see whether we can
0:16:46.160,0:16:51.839
distinguish these
0:16:47.600,0:16:51.839
two cases
0:16:56.240,0:17:00.160
so here we get all the strings
0:17:00.639,0:17:04.559
if we want to see if it's single quotes
0:17:04.079,0:17:07.520
or
0:17:04.559,0:17:07.520
double quote strings
0:17:08.799,0:17:12.480
we can try looking at the first
0:17:11.039,0:17:15.280
character
0:17:12.480,0:17:16.720
of the string I mean the first character
0:17:15.280,0:17:19.360
of the note
0:17:16.720,0:17:33.600
to check whether it's a single quote or
0:17:19.360,0:17:36.080
a double quote
0:17:33.600,0:17:36.799
yeah so for that we use the three
0:17:36.080,0:17:40.160
setters
0:17:36.799,0:17:43.360
support for predicate in this case
0:17:40.160,0:17:46.080
we use a match predicate
0:17:43.360,0:17:46.799
to check whether the string where the
0:17:46.080,0:17:50.320
note
0:17:46.799,0:17:51.280
starts with a single quote and with this
0:17:50.320,0:17:55.520
pattern
0:17:51.280,0:17:55.520
we only capture the single quotes
0:17:58.840,0:18:03.760
strings
0:18:00.400,0:18:07.760
let's try to give it a different face
0:18:03.760,0:18:07.760
so we copy the pattern
0:18:13.039,0:18:16.640
and we add this pattern
0:18:18.640,0:18:21.760
pop item only
0:18:25.120,0:18:31.440
but we also want to give the
0:18:28.400,0:18:36.320
capture a different name
0:18:31.440,0:18:36.320
let's say we want to highlight it as a
0:18:40.840,0:18:43.840
keyword
0:18:46.559,0:18:57.840
and now if we refresh the buffer
0:19:06.320,0:19:10.320
we see that single quote strings are
0:19:08.799,0:19:12.880
highlighted as
0:19:10.320,0:19:12.880
keywords
0:19:14.400,0:19:19.200
the highlighting patterns can also be
0:19:16.400,0:19:23.280
set for a single project
0:19:19.200,0:19:23.280
using directory local variable
0:19:23.440,0:19:30.000
for example let's take a look at
0:19:26.880,0:19:30.000
ems source code
0:19:35.760,0:19:43.760
so in image c source there are a lot of
0:19:40.400,0:19:47.679
uses of these different macros
0:19:43.760,0:19:50.400
to define functions
0:19:47.679,0:19:50.400
and you can see
0:19:51.200,0:19:55.760
this is actually the function name but
0:19:53.520,0:19:59.120
it's highlighted as the
0:19:55.760,0:20:03.679
string so what we want
0:19:59.120,0:20:07.600
is to somehow recognize this pattern
0:20:03.679,0:20:11.280
and highlight it
0:20:07.600,0:20:14.559
as highlight this part
0:20:11.280,0:20:17.679
with the function phase instead
0:20:14.559,0:20:20.240
in order to do that
0:20:17.679,0:20:21.760
we put a pattern in this project
0:20:20.240,0:20:24.880
directory local
0:20:21.760,0:20:24.880
settings file
0:20:31.760,0:20:37.760
so we can put this button in the c
0:20:34.799,0:20:37.760
mode section
0:20:40.159,0:20:50.480
and now if we enable tree sitter
0:20:48.000,0:20:52.720
you can see that this is the highlighted
0:20:50.480,0:20:52.720
uh
0:20:53.200,0:20:56.559
as a normal function definition so this
0:20:55.520,0:21:00.400
is the function
0:20:56.559,0:21:00.400
face like we wanted
0:21:01.200,0:21:06.080
the pattern for this is actually pretty
0:21:03.760,0:21:06.080
simple
0:21:07.200,0:21:09.919
it's only
0:21:10.720,0:21:17.440
only this part so
0:21:14.720,0:21:19.679
if it's a function call where the name
0:21:17.440,0:21:21.600
of the function is different
0:21:19.679,0:21:24.159
then we highlight the different as a
0:21:21.600,0:21:24.159
keyword
0:21:24.240,0:21:28.159
and then the first string element we
0:21:27.360,0:21:31.840
highlighted
0:21:28.159,0:21:31.840
as a function name
0:21:35.360,0:21:39.280
since the language objects are actually
0:21:37.679,0:21:40.799
native code
0:21:39.280,0:21:43.440
they have to be compiled for each
0:21:40.799,0:21:45.600
platform that we want to support
0:21:43.440,0:21:48.159
this will become a big obstacle for
0:21:45.600,0:21:50.240
3-seater adoption
0:21:48.159,0:21:52.960
therefore I've created a language window
0:21:50.240,0:21:54.960
package 3-seater length
0:21:52.960,0:21:56.320
that takes care of pre-compiling the
0:21:54.960,0:21:59.679
grammars the
0:21:56.320,0:22:01.600
most common grammars for all three major
0:21:59.679,0:22:04.080
platforms
0:22:01.600,0:22:05.360
it also takes care of distributing these
0:22:04.080,0:22:08.080
binaries
0:22:05.360,0:22:11.280
and provides some highlighting queries
0:22:08.080,0:22:11.280
for some of the languages
0:22:11.440,0:22:15.919
it should be noted that this package
0:22:13.760,0:22:19.520
should be treated as a temporary
0:22:15.919,0:22:19.520
distribution mechanism only
0:22:19.919,0:22:24.720
to help with bootstrapping three-seaters
0:22:22.240,0:22:27.760
adoption
0:22:24.720,0:22:29.760
the plan is that eventually these files
0:22:27.760,0:22:32.480
should be provided by the language major
0:22:29.760,0:22:35.120
modes themselves
0:22:32.480,0:22:36.320
but in order to do that we need better
0:22:35.120,0:22:40.240
tooling
0:22:36.320,0:22:42.559
so we're not there yet
0:22:40.240,0:22:43.280
since the call already works reasonably
0:22:42.559,0:22:44.640
well
0:22:43.280,0:22:46.320
there are several areas that would
0:22:44.640,0:22:48.960
benefit from the community's
0:22:46.320,0:22:48.960
contribution
0:22:49.120,0:22:52.640
so three seaters upstream language
0:22:51.520,0:22:54.400
prepositories
0:22:52.640,0:22:55.679
already contain highlighting queries on
0:22:54.400,0:22:58.480
their own
0:22:55.679,0:23:00.480
however they are pretty basic and they
0:22:58.480,0:23:02.559
may not fit well with existing emax
0:23:00.480,0:23:04.320
conventions
0:23:02.559,0:23:07.120
therefore the language bundle has its
0:23:04.320,0:23:10.559
own set of highlighting queries
0:23:07.120,0:23:11.600
this requires maintenance until language
0:23:10.559,0:23:13.760
measurements adopt
0:23:11.600,0:23:16.240
three sitter and maintain the queries on
0:23:13.760,0:23:16.240
their own
0:23:16.640,0:23:22.000
the queries are actually quite easy to
0:23:18.480,0:23:24.240
write as you've already seen
0:23:22.000,0:23:25.360
you just need to be familiar with the
0:23:24.240,0:23:30.000
language
0:23:25.360,0:23:32.880
familiar enough to come up with sensible
0:23:30.000,0:23:32.880
highlighting patterns
0:23:35.200,0:23:39.679
and if you are a maintainer of a
0:23:37.600,0:23:42.320
language major mode
0:23:39.679,0:23:43.360
you may want to consider integrating
0:23:42.320,0:23:46.960
tree sitter into
0:23:43.360,0:23:50.080
your mode initially maybe as an
0:23:46.960,0:23:53.279
optional feature the integration is
0:23:50.080,0:23:56.640
actually pretty straightforward
0:23:53.279,0:24:00.880
especially for syntax highlighting
0:23:56.640,0:24:00.880
or alternatively
0:24:01.520,0:24:04.640
you can also try writing a new major
0:24:03.760,0:24:08.000
mode
0:24:04.640,0:24:11.360
from scratch that relies on tree sitter
0:24:08.000,0:24:11.360
from the very beginning
0:24:12.559,0:24:19.679
the code for such a major mode is
0:24:16.320,0:24:23.200
quite simple for example
0:24:19.679,0:24:26.240
this is the proposed
0:24:23.200,0:24:30.720
what mode for web assembly
0:24:26.240,0:24:30.720
the code is just
0:24:31.039,0:24:37.120
like one page of code not
0:24:34.559,0:24:37.120
not a lot
0:24:39.520,0:24:46.559
you can also try writing new minor modes
0:24:42.720,0:24:50.080
or writing integration packages
0:24:46.559,0:24:50.880
for example a lot of package a lot of
0:24:50.080,0:24:54.559
packages
0:24:50.880,0:24:58.840
may benefit from tree sitter integration
0:24:54.559,0:25:01.840
but no one has written the integration
0:24:58.840,0:25:01.840
yet
0:25:02.960,0:25:06.720
if you are interested in 3-seater you
0:25:05.039,0:25:10.320
can use these links to
0:25:06.720,0:25:11.440
learn more about it I think that's it
0:25:10.320,0:25:18.159
for me today
0:25:11.440,0:25:18.159
I'm happy to answer any questions
