Changes so far

1 files changed, 347 insertions, 462 deletions

diff --git a/2020/subtitles/emacsconf-2020--23-incremental-parsing-with-emacs-tree-sitter--tuan-anh-nguyen-autogen.vtt b/2020/subtitles/emacsconf-2020--23-incremental-parsing-with-emacs-tree-sitter--tuan-anh-nguyen-autogen.vtt
index 99133c78..62ad5f65 100644
--- a/2020/subtitles/emacsconf-2020--23-incremental-parsing-with-emacs-tree-sitter--tuan-anh-nguyen-autogen.vtt
+++ b/2020/subtitles/emacsconf-2020--23-incremental-parsing-with-emacs-tree-sitter--tuan-anh-nguyen-autogen.vtt
@@ -1,724 +1,609 @@
 WEBVTT
 
 00:00:01.520 --> 00:00:04.400
-hello everyone my name is toniang
+Hello, everyone! My name is Tuấn-Anh.
 
 00:00:04.400 --> 00:00:07.200
-I've been using amax for about 10 years
+I've been using Emacs for about 10 years.
 
 00:00:07.200 --> 00:00:09.280
-today I'm going to talk about 360
+Today, I'm going to talk about tree-sitter,
 
-00:00:09.280 --> 00:00:11.519
-a new imax package that allows ems to
+00:00:09.280 --> 00:00:11.351
+a new Emacs package that allows Emacs
 
-00:00:11.519 --> 00:00:13.759
-pass multiple programming languages
-
-00:00:13.759 --> 00:00:17.840
-in real time
+00:00:11.351 --> 00:00:17.840
+to parse multiple programming languages
+in real-time.
 
 00:00:17.840 --> 00:00:21.840
-so what is the problem statement
-
-00:00:21.840 --> 00:00:23.359
-in order to support programming
+So what is the problem statement?
 
-00:00:23.359 --> 00:00:24.960
-functionalities for a particular
+00:00:21.840 --> 00:00:24.131
+In order to support programming
+functionalities
 
-00:00:24.960 --> 00:00:25.760
-language
+00:00:24.131 --> 00:00:25.760
+for a particular language,
 
 00:00:25.760 --> 00:00:27.680
 a text editor needs to have some degree
 
 00:00:27.680 --> 00:00:29.679
-of language understanding
+of language understanding.
 
 00:00:29.679 --> 00:00:31.840
-traditionally text editors have relied
+Traditionally, text editors have relied
 
-00:00:31.840 --> 00:00:33.840
+00:00:31.840 --> 00:00:34.960
 very heavily on regular expressions for
+this.
 
-00:00:33.840 --> 00:00:34.960
-this
-
-00:00:34.960 --> 00:00:38.320
-e-max is no different most language
-
-00:00:38.320 --> 00:00:39.280
-major modes use
-
-00:00:39.280 --> 00:00:40.879
-regular expressions for syntax
-
-00:00:40.879 --> 00:00:42.960
-highlighting code navigation
-
-00:00:42.960 --> 00:00:46.239
-folding indexing and so on regular
-
-00:00:46.239 --> 00:00:47.440
-expressions are
+00:00:34.960 --> 00:00:37.013
+Emacs is no different.
 
-00:00:47.440 --> 00:00:50.559
-problematic for a couple of reasons
+00:00:37.013 --> 00:00:40.170
+Most language major modes use regular
+expressions
 
-00:00:50.559 --> 00:00:53.600
-they're slow and inaccurate they also
+00:00:40.170 --> 00:00:42.960
+for syntax-highlighting, code navigation,
 
-00:00:53.600 --> 00:00:54.000
-make
+00:00:42.960 --> 00:00:46.618
+folding, indexing, and so on.
 
-00:00:54.000 --> 00:00:56.800
-the code hard to read and write
+00:00:46.618 --> 00:00:50.559
+Regular expressions are problematic for
+a couple of reasons.
 
-00:00:56.800 --> 00:00:57.440
-sometimes
+00:00:50.559 --> 00:00:53.778
+They're slow and inaccurate.
 
-00:00:57.440 --> 00:00:59.199
-it's because the regular expressions
+00:00:53.778 --> 00:00:56.800
+They also make the code hard to read and
+write.
 
-00:00:59.199 --> 00:01:01.199
-themselves are very hairy
+00:00:56.800 --> 00:01:01.199
+Sometimes it's because the regular
+expressions themselves are very hairy,
 
-00:01:01.199 --> 00:01:04.000
+00:01:01.199 --> 00:01:05.199
 and sometimes because they are just not
+powerful enough.
 
-00:01:04.000 --> 00:01:05.199
-powerful enough
-
-00:01:05.199 --> 00:01:07.840
-some helper code is usually needed to
+00:01:05.199 --> 00:01:08.625
+Some helper code is usually needed
 
-00:01:07.840 --> 00:01:11.200
-pass more intricate language features
+00:01:08.625 --> 00:01:11.200
+to parse more intricate language
+features.
 
-00:01:11.200 --> 00:01:13.280
-that also illustrates the core problem
+00:01:11.200 --> 00:01:16.159
+That also illustrates the core problem
+with regular expressions,
 
-00:01:13.280 --> 00:01:16.159
-with regular expressions
-
-00:01:16.159 --> 00:01:18.400
+00:01:16.159 --> 00:01:21.119
 in that they are not powerful enough to
+parse programming languages.
 
-00:01:18.400 --> 00:01:21.119
-pass programming languages
-
-00:01:21.119 --> 00:01:22.640
-an example feature that regular
-
-00:01:22.640 --> 00:01:25.040
+00:01:21.119 --> 00:01:25.040
+An example feature that regular
 expressions cannot handle very well
 
-00:01:25.040 --> 00:01:27.520
-is string interpolation which is a very
-
-00:01:27.520 --> 00:01:28.320
+00:01:25.040 --> 00:01:28.320
+is string interpolation, which is a very
 common feature
 
 00:01:28.320 --> 00:01:31.680
-in many modern programming languages
+in many modern programming languages.
 
 00:01:31.680 --> 00:01:34.079
-it would be much nicer if image somehow
+It would be much nicer if Emacs somehow
 
-00:01:34.079 --> 00:01:35.840
+00:01:34.079 --> 00:01:39.520
 had structural understanding of source
+code, like IDEs do.
 
-00:01:35.840 --> 00:01:36.479
-code
-
-00:01:36.479 --> 00:01:39.520
-like ides do
-
-00:01:39.520 --> 00:01:41.119
-there have been multiple efforts to
+00:01:39.520 --> 00:01:41.981
+There have been multiple efforts
 
-00:01:41.119 --> 00:01:42.960
-bring this kind of programming language
-
-00:01:42.960 --> 00:01:45.280
-understanding into Emacs
+00:01:41.981 --> 00:01:45.280
+to bring this kind of programming
+language understanding into Emacs.
 
 00:01:45.280 --> 00:01:47.119
-there are language specific persons
+There are language-specific parsers
 
 00:01:47.119 --> 00:01:48.640
-written in elise
-
-00:01:48.640 --> 00:01:50.240
-they can be thought of as the next
+written in Elisp
 
-00:01:50.240 --> 00:01:52.320
-logical step of the glue code on top
+00:01:48.640 --> 00:01:50.675
+that can be thought of
 
-00:01:52.320 --> 00:01:54.960
-of tribal expressions moving from
+00:01:50.675 --> 00:01:51.989
+as the next logical step
+of the glue code
 
-00:01:54.960 --> 00:01:56.000
-partial local
+00:01:51.989 --> 00:01:53.856
+on top of regular expressions,
 
-00:01:56.000 --> 00:01:58.079
-pattern recognition into a full-fledged
+00:01:53.856 --> 00:01:57.356
+moving from partial local pattern
+recognition
 
-00:01:58.079 --> 00:01:59.840
-parser
+00:01:57.356 --> 00:01:59.840
+into a full-fledged parser.
 
-00:01:59.840 --> 00:02:01.439
-the most prominent example of this
+00:01:59.840 --> 00:02:02.023
+The most prominent example of this
+approach
 
-00:02:01.439 --> 00:02:03.040
-approach is probably the famous
-
-00:02:03.040 --> 00:02:06.479
-js2 mode
+00:02:02.023 --> 00:02:06.479
+is probably the famous js2-mode.
 
 00:02:06.479 --> 00:02:10.080
-however this approach has several issues
-
-00:02:10.080 --> 00:02:12.959
-parsing is computationally expensive and
+However, this approach has several issues.
 
-00:02:12.959 --> 00:02:13.680
-imagine
+00:02:10.080 --> 00:02:12.606
+Parsing is computationally expensive,
 
-00:02:13.680 --> 00:02:16.800
-is not good at that kind of stuff
+00:02:12.606 --> 00:02:16.800
+and Emacs Lisp is not good at that kind
+of stuff.
 
-00:02:16.800 --> 00:02:18.400
-furthermore maintenance is very
+00:02:16.800 --> 00:02:19.156
+Furthermore, maintenance is very
+troublesome.
 
-00:02:18.400 --> 00:02:20.840
-troublesome in order to work on these
+00:02:19.156 --> 00:02:22.160
+In order to work on these parsers,
 
-00:02:20.840 --> 00:02:22.160
-process
+00:02:22.160 --> 00:02:24.239
+first, you have to know Elisp
+well enough,
 
-00:02:22.160 --> 00:02:23.599
-first you have to know at least well
+00:02:24.239 --> 00:02:26.606
+and then you have to be comfortable with
 
-00:02:23.599 --> 00:02:25.599
-enough and then you have to be
+00:02:26.606 --> 00:02:29.739
+writing a recursive descending parser,
 
-00:02:25.599 --> 00:02:27.760
-comfortable with writing a
+00:02:29.739 --> 00:02:34.000
+while constantly keeping up with changes
+to the language itself,
 
-00:02:27.760 --> 00:02:30.319
-recursive ascendant parser while
+00:02:34.000 --> 00:02:36.356
+which can be evolving very quickly,
 
-00:02:30.319 --> 00:02:32.080
-constantly keeping up with changes to
+00:02:36.356 --> 00:02:39.360
+like Javascript, for example.
 
-00:02:32.080 --> 00:02:34.000
-the language itself
+00:02:39.360 --> 00:02:42.373
+Together, these constraints
+significantly reduce
 
-00:02:34.000 --> 00:02:36.879
-which can be evolving very quickly like
-
-00:02:36.879 --> 00:02:39.360
-javascript for example
-
-00:02:39.360 --> 00:02:41.599
-together these constraints significantly
-
-00:02:41.599 --> 00:02:45.680
-reduce the pull of potential maintenance
+00:02:42.373 --> 00:02:45.680
+the pool of potential maintainers.
 
 00:02:45.680 --> 00:02:47.760
-the biggest issue though in my opinion
-
-00:02:47.760 --> 00:02:49.680
-is lack of the set of generic
+The biggest issue, though, in my opinion,
 
-00:02:49.680 --> 00:02:52.879
-and reusable apis this makes them very
+00:02:47.760 --> 00:02:52.139
+is lack of the set of generic and
+reusable APIs.
 
-00:02:52.879 --> 00:02:54.319
-hard to use
+00:02:52.139 --> 00:02:54.319
+This makes them very hard to use
 
 00:02:54.319 --> 00:02:55.920
 for minor modes that want to deal with
 
-00:02:55.920 --> 00:02:57.920
+00:02:55.920 --> 00:02:59.920
 cross-cutting concerns across multiple
-
-00:02:57.920 --> 00:02:59.920
-languages
+languages.
 
 00:02:59.920 --> 00:03:01.760
-the other approach which has been
-
-00:03:01.760 --> 00:03:03.599
-gaining a lot of momentum in recent
+The other approach which has been
 
-00:03:03.599 --> 00:03:04.319
-years
+00:03:01.760 --> 00:03:04.319
+gaining a lot of momentum
+in recent years
 
 00:03:04.319 --> 00:03:06.560
 is externalizing language understanding
 
 00:03:06.560 --> 00:03:08.159
-to another process
+to another process,
 
 00:03:08.159 --> 00:03:12.239
-also known as language server protocol
+also known as language server protocol.
 
-00:03:12.239 --> 00:03:14.480
-this second approach is actually a very
-
-00:03:14.480 --> 00:03:16.560
-interesting one
+00:03:12.239 --> 00:03:16.560
+This second approach is actually a very
+interesting one.
 
 00:03:16.560 --> 00:03:18.400
-my decoupling language understanding
+By decoupling language understanding
 
 00:03:18.400 --> 00:03:21.280
-from the editing facility itself
-
-00:03:21.280 --> 00:03:23.760
-the usb servers can attract a lot more
+from the editing facility itself,
 
-00:03:23.760 --> 00:03:25.120
-contributors
+00:03:21.280 --> 00:03:25.120
+the LSP servers can attract a lot more
+contributors,
 
-00:03:25.120 --> 00:03:28.959
-which makes maintenance easier however
+00:03:25.120 --> 00:03:27.189
+which makes maintenance easier.
 
-00:03:28.959 --> 00:03:32.400
-they also have several issues available
+00:03:27.189 --> 00:03:32.400
+However, they also have several issues
+of their own.
 
-00:03:32.400 --> 00:03:34.720
-being a separate process they are
+00:03:32.400 --> 00:03:34.089
+Being a separate process,
 
-00:03:34.720 --> 00:03:36.000
-usually more resource
+00:03:34.089 --> 00:03:37.073
+they are usually more
+resource-intensive,
 
-00:03:36.000 --> 00:03:39.920
-intensive and depending on the language
+00:03:37.073 --> 00:03:39.920
+and depending on the language,
 
 00:03:39.920 --> 00:03:42.159
-the usb server itself can bring with it
+the LSP server itself can bring with it
 
 00:03:42.159 --> 00:03:44.640
 a host of additional dependencies
 
-00:03:44.640 --> 00:03:47.680
-external to Emacs which may message to
+00:03:44.640 --> 00:03:50.640
+external to Emacs, which may be messy to
+install and manage.
 
-00:03:47.680 --> 00:03:50.640
-install and manage
-
-00:03:50.640 --> 00:03:53.760
-furthermore json over rpc has pretty
-
-00:03:53.760 --> 00:03:55.120
-high latency
+00:03:50.640 --> 00:03:55.120
+Furthermore, JSON over RPC has pretty
+high latency.
 
 00:03:55.120 --> 00:03:57.840
-for one-off tasks like jumping to source
+For one-off tasks like jumping to source
 
 00:03:57.840 --> 00:04:00.879
-or on-demand completion is great
+or on-demand completion, it's great.
 
 00:04:00.879 --> 00:04:03.040
-but for things like code highlighting
+But for things like code highlighting,
 
 00:04:03.040 --> 00:04:06.000
-the latency is just too much
+the latency is just too much.
 
 00:04:06.000 --> 00:04:08.319
-I was using rust and I was following the
+I was using Rust and I was following the
 
-00:04:08.319 --> 00:04:10.480
-community effort to improve its id
+00:04:08.319 --> 00:04:11.760
+community effort to improve its
+IDE support,
 
-00:04:10.480 --> 00:04:11.760
-support
-
-00:04:11.760 --> 00:04:13.680
+00:04:11.760 --> 00:04:15.760
 hoping to integrate some of that into
+Emacs itself.
 
-00:04:13.680 --> 00:04:15.760
-Emacs itself
-
-00:04:15.760 --> 00:04:17.600
-then I heard someone from community
-
-00:04:17.600 --> 00:04:19.759
-mention tree sitter
+00:04:15.760 --> 00:04:19.759
+Then I heard someone from the community
+mention tree-sitter,
 
 00:04:19.759 --> 00:04:23.360
-and I decided to check it out
-
-00:04:23.360 --> 00:04:25.520
-basically trisita is an incremental
+and I decided to check it out.
 
-00:04:25.520 --> 00:04:28.720
-parsing library and a parser generator
+00:04:23.360 --> 00:04:28.720
+Basically, tree-sitter is an incremental
+parsing library and a parser generator.
 
-00:04:28.720 --> 00:04:31.000
-it was introduced by the item editor in
+00:04:28.720 --> 00:04:33.040
+It was introduced by the Atom editor in
+2018.
 
-00:04:31.000 --> 00:04:33.040
-2018
+00:04:33.040 --> 00:04:35.923
+Besides Atom, it is also being
+integrated
 
-00:04:33.040 --> 00:04:35.680
-besides item is also being integrated
+00:04:35.923 --> 00:04:37.623
+into the NeoVim editor,
 
-00:04:35.680 --> 00:04:36.960
-into the neo-vim
+00:04:37.623 --> 00:04:41.040
+and Github is using it to power
 
-00:04:36.960 --> 00:04:41.040
-editor and github is using it to power
+00:04:41.040 --> 00:04:42.423
+their source code analysis
 
-00:04:41.040 --> 00:04:42.479
-their source code analysis and
-
-00:04:42.479 --> 00:04:45.840
-navigation features
+00:04:42.423 --> 00:04:45.840
+and navigation features.
 
 00:04:45.840 --> 00:04:48.639
-it is written in c and can be compiled
-
-00:04:48.639 --> 00:04:49.199
-for all
+It is written in C and can be compiled
 
-00:04:49.199 --> 00:04:53.120
-major platforms it can even be compiled
+00:04:48.639 --> 00:04:50.623
+for all major platforms.
 
-00:04:53.120 --> 00:04:56.080
-to web assembly to run on the web that's
+00:04:50.623 --> 00:04:53.120
+It can even be compiled
 
-00:04:56.080 --> 00:04:57.600
-how github is using it
+00:04:53.120 --> 00:04:55.323
+to web assembly to run on the web.
 
-00:04:57.600 --> 00:05:00.800
-on their website
+00:04:55.323 --> 00:05:00.800
+That's how Github is using it
+on their website.
 
-00:05:00.800 --> 00:05:02.960
-so why is trisita an interesting
+00:05:00.800 --> 00:05:05.840
+So why is tree-sitter an interesting
+solution to this problem?
 
-00:05:02.960 --> 00:05:05.840
-solution to this problem
+00:05:05.840 --> 00:05:10.000
+There are multiple features that make it
+an attractive option.
 
-00:05:05.840 --> 00:05:07.360
-there are multiple features that make it
+00:05:10.000 --> 00:05:11.839
+It is designed to be fast.
 
-00:05:07.360 --> 00:05:10.000
-an attractive option
-
-00:05:10.000 --> 00:05:12.400
-it is designed to be fast by being
-
-00:05:12.400 --> 00:05:13.680
-incremental
+00:05:11.839 --> 00:05:13.680
+By being incremental,
 
 00:05:13.680 --> 00:05:15.680
-the initial parts of a typical big fight
+the initial parse of a typical big file
 
 00:05:15.680 --> 00:05:18.160
-can take tens of milliseconds
+can take tens of milliseconds,
 
 00:05:18.160 --> 00:05:20.240
 while subsequent incremental processes
 
 00:05:20.240 --> 00:05:22.560
-are sub milliseconds
+are sub-millisecond.
 
-00:05:22.560 --> 00:05:24.720
-it achieves this by using structural
-
-00:05:24.720 --> 00:05:26.240
-sharing
+00:05:22.560 --> 00:05:26.240
+It achieves this by using
+structural sharing,
 
 00:05:26.240 --> 00:05:29.360
 meaning replacing only affected nodes
 
 00:05:29.360 --> 00:05:32.960
-in the old tree when it needs to
-
-00:05:32.960 --> 00:05:36.000
-also unlike lsp being in the same
+in the old tree when it needs to.
 
-00:05:36.000 --> 00:05:37.120
-process
+00:05:32.960 --> 00:05:37.120
+Also, unlike LSP, being in
+the same process,
 
 00:05:37.120 --> 00:05:40.639
-it has much lower latency
+it has much lower latency.
 
-00:05:40.639 --> 00:05:42.880
-secondly it provides a uniform
-
-00:05:42.880 --> 00:05:44.960
-programming interface
+00:05:40.639 --> 00:05:44.960
+Secondly, it provides a uniform
+programming interface.
 
 00:05:44.960 --> 00:05:47.039
-the same data structures and functions
+The same data structures and functions
 
-00:05:47.039 --> 00:05:48.720
+00:05:47.039 --> 00:05:50.400
 work on parse trees of different
-
-00:05:48.720 --> 00:05:50.400
-languages
+languages.
 
 00:05:50.400 --> 00:05:52.160
-syntax knows of different languages
+Syntax nodes of different languages
 
 00:05:52.160 --> 00:05:54.160
 differ only by their types
 
-00:05:54.160 --> 00:05:57.360
-and their possible child nodes this
-
-00:05:57.360 --> 00:05:58.960
-is a big advantage over language
-
-00:05:58.960 --> 00:06:02.240
-specific parcels
+00:05:54.160 --> 00:05:55.723
+and their possible child nodes.
 
-00:06:02.240 --> 00:06:04.880
-thirdly it's written in self-contained
+00:05:55.723 --> 00:06:02.240
+This is a big advantage over
+language-specific parsers.
 
-00:06:04.880 --> 00:06:06.880
-embeddable c
+00:06:02.240 --> 00:06:06.880
+Thirdly, it's written in self-contained
+embeddable C.
 
-00:06:06.880 --> 00:06:09.680
-as I mentioned previously it can even be
+00:06:06.880 --> 00:06:11.723
+As I mentioned previously, it can even
+be compiled to webassembly.
 
-00:06:09.680 --> 00:06:10.400
-compiled
+00:06:11.723 --> 00:06:16.106
+This makes integrating it into various
+editors quite easy
 
-00:06:10.400 --> 00:06:13.759
-to webassembly this makes integrating it
+00:06:16.106 --> 00:06:22.880
+without having to install any external
+dependencies.
 
-00:06:13.759 --> 00:06:15.199
-into various editors
+00:06:22.880 --> 00:06:25.503
+One thing that is not mentioned here
 
-00:06:15.199 --> 00:06:18.240
-quite easy without having to install
-
-00:06:18.240 --> 00:06:22.880
-any external dependencies
-
-00:06:22.880 --> 00:06:24.639
-one thing that is not mentioned here is
-
-00:06:24.639 --> 00:06:28.000
-that being a parcel generator
+00:06:25.503 --> 00:06:28.000
+is that being a parser generator,
 
 00:06:28.000 --> 00:06:31.039
-scrummers are declarative
+its grammars are declarative.
 
 00:06:31.039 --> 00:06:34.880
-together with being editor independent
+Together with being editor-independent,
 
-00:06:34.880 --> 00:06:36.720
+00:06:34.880 --> 00:06:39.139
 this makes the pool of potential
+contributors much larger.
 
-00:06:36.720 --> 00:06:38.160
-contributors
-
-00:06:38.160 --> 00:06:42.400
-much larger so I was convinced
-
-00:06:42.400 --> 00:06:45.520
-that trisito is a good fit for Emacs
+00:06:39.139 --> 00:06:45.520
+So I was convinced that tree-sitter is a
+good fit for Emacs.
 
 00:06:45.520 --> 00:06:48.000
-last year I started writing the bindings
-
-00:06:48.000 --> 00:06:48.720
-using
-
-00:06:48.720 --> 00:06:50.960
-dynamic model support introduced in imax
-
-00:06:50.960 --> 00:06:53.280
-25.
+Last year, I started writing the bindings
 
-00:06:53.280 --> 00:06:55.360
-dynamic module means there is platform
+00:06:48.000 --> 00:06:53.280
+using dynamic module support introduced
+in Emacs 25.
 
-00:06:55.360 --> 00:06:58.479
-specific native code involved
+00:06:53.280 --> 00:06:58.479
+Dynamic module means there is
+platform-specific native code involved,
 
 00:06:58.479 --> 00:07:00.560
-but since they are pre-compiled binaries
+but since there are pre-compiled binaries
 
 00:07:00.560 --> 00:07:02.880
-for the three major platforms
+for the three major platforms,
 
-00:07:02.880 --> 00:07:06.319
-it should work in most places currently
+00:07:02.880 --> 00:07:04.706
+it should work in most places.
 
-00:07:06.319 --> 00:07:08.319
-the core functionalities are in a pretty
-
-00:07:08.319 --> 00:07:09.440
-good shape
+00:07:04.706 --> 00:07:09.440
+Currently, the core functionalities are
+in a pretty good shape.
 
 00:07:09.440 --> 00:07:12.560
-syntax highlighting is working nicely
-
-00:07:12.560 --> 00:07:14.840
-the whole thing is split into three
-
-00:07:14.840 --> 00:07:16.080
-packages
+Syntax highlighting is working nicely.
 
-00:07:16.080 --> 00:07:17.759
-tree sitter is the main package that
+00:07:12.560 --> 00:07:16.080
+The whole thing is split into three
+packages.
 
-00:07:17.759 --> 00:07:20.319
-other packages should depend on
+00:07:16.080 --> 00:07:20.319
+tree-sitter is the main package that
+other packages should depend on.
 
 00:07:20.319 --> 00:07:22.800
-tree system lens is the language bundle
+tree-sitter-langs is the language bundle
 
 00:07:22.800 --> 00:07:24.000
 that includes support
 
 00:07:24.000 --> 00:07:27.199
-for most common languages
+for most common languages.
 
-00:07:27.199 --> 00:07:30.080
-and finally the core apis are in the
-
-00:07:30.080 --> 00:07:32.160
-package tsc
+00:07:27.199 --> 00:07:32.160
+And finally, the core APIs are in the
+package tsc,
 
 00:07:32.160 --> 00:07:36.160
-which stands for trees the core
+which stands for tree-sitter-core.
 
 00:07:36.160 --> 00:07:38.800
-it is the implicit dependency of the
+It is the implicit dependency of the
 
 00:07:38.800 --> 00:07:43.520
-three-seater package
-
-00:07:43.520 --> 00:07:46.000
-the main package includes the miner mode
-
-00:07:46.000 --> 00:07:47.520
-3-seater mode
-
-00:07:47.520 --> 00:07:49.840
-this provides the base for other major
+tree-sitter package.
 
-00:07:49.840 --> 00:07:52.560
-or minor modes to build on
+00:07:43.520 --> 00:07:47.520
+The main package includes the minor mode
+tree-sitter-mode.
 
-00:07:52.560 --> 00:07:55.280
-using image change tracking hooks it
+00:07:47.520 --> 00:07:52.560
+This provides the base for other major
+or minor modes to build on.
 
-00:07:55.280 --> 00:07:55.840
-enables
+00:07:52.560 --> 00:07:54.839
+Using Emacs's change tracking hooks,
 
-00:07:55.840 --> 00:07:58.080
-incremental parsing and provides a
+00:07:54.839 --> 00:07:57.073
+it enables incremental parsing
 
-00:07:58.080 --> 00:08:00.800
-syntax tree that is always up to date
+00:07:57.073 --> 00:08:00.800
+and provides a syntax tree that is
+always up to date
 
 00:08:00.800 --> 00:08:04.080
-after any edits in a buffer
+after any edits in a buffer.
 
-00:08:04.080 --> 00:08:06.560
-there is also a basic debug mode that
+00:08:04.080 --> 00:08:06.223
+There is also a basic debug mode
 
-00:08:06.560 --> 00:08:10.080
-shows the parse tree in another buffer
+00:08:06.223 --> 00:08:10.080
+that shows the parse tree in
+another buffer.
 
 00:08:10.080 --> 00:08:13.360
-here is a quick demo
+Here is a quick demo.
 
-00:08:13.360 --> 00:08:15.759
-here I mean an empty python buffer with
+00:08:13.360 --> 00:08:15.673
+Here I'm in an empty Python buffer
 
-00:08:15.759 --> 00:08:17.520
-three seater enabled
+00:08:15.673 --> 00:08:17.520
+with tree-sitter enabled.
 
 00:08:17.520 --> 00:08:19.440
 I'm going to turn on the debug mode to
 
 00:08:19.440 --> 00:08:26.560
-see the parse tree
+see the parse tree.
 
-00:08:26.560 --> 00:08:28.720
-since the buffer is empty there is only
+00:08:26.560 --> 00:08:28.106
+Since the buffer is empty,
 
-00:08:28.720 --> 00:08:30.639
-one node in the syntax tree the top
+00:08:28.106 --> 00:08:30.423
+there is only one node in the
+syntax tree:
 
-00:08:30.639 --> 00:08:33.279
-level module node
+00:08:30.423 --> 00:08:33.279
+the top-level module node.
 
 00:08:33.279 --> 00:09:11.040
-let's try typing some code
+Let's try typing some code.
 
-00:09:11.040 --> 00:09:13.600
-as you can see as I type into the python
-
-00:09:13.600 --> 00:09:14.640
-buffer
+00:09:11.040 --> 00:09:14.640
+As you can see, as I type into the
+Python buffer,
 
 00:09:14.640 --> 00:09:19.120
-the syntax tree updates in real time
-
-00:09:19.120 --> 00:09:21.120
-the other minor mode included in the
+the syntax tree updates in real time.
 
-00:09:21.120 --> 00:09:23.279
-main package is 3-seater
+00:09:19.120 --> 00:09:22.039
+The other minor mode included in the
+main package
 
-00:09:23.279 --> 00:09:26.640
-hl mode it overrides font-lock mode and
+00:09:22.039 --> 00:09:24.389
+is tree-sitter-hl-mode.
 
-00:09:26.640 --> 00:09:28.480
-provides its own set of phases
+00:09:24.389 --> 00:09:26.349
+It overrides font-lock mode
 
-00:09:28.480 --> 00:09:31.839
-and customization options it is query
+00:09:26.349 --> 00:09:28.480
+and provides its own set of phases
 
-00:09:31.839 --> 00:09:32.800
-driven
+00:09:28.480 --> 00:09:30.139
+and customization options
 
-00:09:32.800 --> 00:09:35.200
-that means instead of regular
+00:09:30.139 --> 00:09:32.800
+It is query-driven.
 
-00:09:35.200 --> 00:09:36.240
-expressions
+00:09:32.800 --> 00:09:36.240
+That means instead of regular
+expressions,
 
-00:09:36.240 --> 00:09:38.720
-it uses a list like query language to
+00:09:36.240 --> 00:09:39.518
+it uses a Lisp-like query language
 
-00:09:38.720 --> 00:09:40.320
-map syntax notes
+00:09:39.518 --> 00:09:40.320
+to map syntax nodes
 
-00:09:40.320 --> 00:09:43.760
-to highlighting phrases I'm going to
+00:09:40.320 --> 00:09:41.923
+to highlighting phrases.
 
-00:09:43.760 --> 00:09:45.760
-open a python file with small snippets
+00:09:41.923 --> 00:09:45.760
+I'm going to open a python file with
+small snippets
 
 00:09:45.760 --> 00:09:54.320
-that showcase syntax highlighting
+that showcase syntax highlighting.
 
 00:09:54.320 --> 00:09:55.920
-so this is the default highlighting
+So this is the default highlighting
 
 00:09:55.920 --> 00:10:00.880
-provided by python mode
-
-00:10:00.880 --> 00:10:02.839
-this is the highlighting enabled by tree
+provided by python-mode.
 
-00:10:02.839 --> 00:10:04.640
-sitter
+00:10:00.880 --> 00:10:04.640
+This is the highlighting enabled
+by tree-sitter.
 
 00:10:04.640 --> 00:10:07.680
 as you can see string interpolation