diff options
| -rw-r--r-- | 2020/subtitles/emacsconf-2020--23-incremental-parsing-with-emacs-tree-sitter--tuan-anh-nguyen-autogen.vtt | 809 |
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 |