path: root/2020/subtitles/emacsconf-2020--23-incremental-parsing-with-emacs-tree-sitter--questions--tuan-anh-nguyen-autogen.sbv

0:00:00.960,0:00:05.600
uh okay so the first question is is uh

0:00:03.679,0:00:08.000
do you think that this package can be

0:00:05.600,0:00:11.760
included into Emacs or

0:00:08.000,0:00:11.760
uh empire uh

0:00:12.320,0:00:18.560
I think uh it most definitely can is

0:00:15.360,0:00:21.760
just a matter of paperwork but

0:00:18.560,0:00:24.480
the reason I initially wanted to make it

0:00:21.760,0:00:25.039
like a central package is that so that I

0:00:24.480,0:00:28.720
can

0:00:25.039,0:00:31.920
experiment with it more

0:00:28.720,0:00:34.320
like have more freedom to experiment but

0:00:31.920,0:00:35.680
eventually I think is a good candidate

0:00:34.320,0:00:37.920
for inclusion into

0:00:35.680,0:00:37.920
core

0:00:38.800,0:00:42.640
and because because currently not in

0:00:41.200,0:00:44.480
corey mass there are a couple of

0:00:42.640,0:00:47.840
problems with it

0:00:44.480,0:00:50.960
mostly in terms of performance

0:00:47.840,0:00:53.280
for example like anytime we want to

0:00:50.960,0:00:54.160
access the text in a buffer we need to

0:00:53.280,0:00:57.360
make

0:00:54.160,0:01:00.480
a copy of the text into a string

0:00:57.360,0:01:03.520
and then right after reading from that

0:01:00.480,0:01:05.280
text we need to free it right away and

0:01:03.520,0:01:09.040
that results in a lot of garbage

0:01:05.280,0:01:11.920
collection so it would be better

0:01:09.040,0:01:12.240
either the treasure could be included in

0:01:11.920,0:01:15.680
core

0:01:12.240,0:01:16.799
imax or dynamic dynamic model support

0:01:15.680,0:01:19.439
can be

0:01:16.799,0:01:21.920
augmented with direct text access

0:01:19.439,0:01:21.920
somehow

0:01:24.080,0:01:27.200
so the second question is will release

0:01:26.400,0:01:30.320
performance

0:01:27.200,0:01:33.040
be more competitive with cce max

0:01:30.320,0:01:35.520
enough so electricity in english is more

0:01:33.040,0:01:35.520
attractive

0:01:35.670,0:01:43.439
[Music]

0:01:38.240,0:01:45.840
I think it's possible but uh yeah

0:01:43.439,0:01:46.799
not sure about the amount of effort it

0:01:45.840,0:01:52.000
can be

0:01:46.799,0:01:52.000
multi-years effort and one thing that

0:01:52.960,0:02:00.640
even though gce max can make uh

0:01:56.479,0:02:00.640
it is fast enough there's

0:02:00.719,0:02:05.280
there's one thing that it uh cannot have

0:02:03.119,0:02:09.679
which is that because it's the lisp

0:02:05.280,0:02:12.480
it needs the garage collector so

0:02:09.679,0:02:14.000
we may experiment experience some kind

0:02:12.480,0:02:17.360
of

0:02:14.000,0:02:19.920
gcc post if we use live whereas the

0:02:17.360,0:02:24.720
currently transistor is written in c

0:02:19.920,0:02:24.720
so there's no such latency

0:02:28.400,0:02:32.400
the next question is do you think three

0:02:31.040,0:02:36.080
sister would be useful

0:02:32.400,0:02:38.319
for all buffers I can imagine it being

0:02:36.080,0:02:39.599
used to keep a post ast about an arc

0:02:38.319,0:02:42.560
buffer

0:02:39.599,0:02:43.920
light off element and update it in real

0:02:42.560,0:02:46.239
time

0:02:43.920,0:02:47.760
yeah actually this is a very interesting

0:02:46.239,0:02:50.800
idea

0:02:47.760,0:02:53.760
I saw someone started

0:02:50.800,0:02:55.120
resistor grammar for all already I don't

0:02:53.760,0:02:58.159
have a link right now but

0:02:55.120,0:03:01.040
I can look for it

0:02:58.159,0:03:01.680
I'll try looking for it and put the link

0:03:01.040,0:03:05.840
in

0:03:01.680,0:03:05.840
here later

0:03:09.599,0:03:15.519
yeah yes someone has written here the uh

0:03:13.280,0:03:17.040
and the biggest problem with uh right

0:03:15.519,0:03:20.560
now is that it doesn't have

0:03:17.040,0:03:20.560
formal grammar so

0:03:21.360,0:03:24.400
so the effort

0:03:22.380,0:03:27.120
[Applause]

0:03:24.400,0:03:28.799
be quite big I think but but once we

0:03:27.120,0:03:31.519
have that because the

0:03:28.799,0:03:33.840
tree sitter can be run on the web as

0:03:31.519,0:03:33.840
well

0:03:34.239,0:03:38.080
we can on the web and in many other

0:03:37.440,0:03:40.720
places

0:03:38.080,0:03:41.840
if we have a grammar for a traditional

0:03:40.720,0:03:45.680
grammar for all

0:03:41.840,0:03:49.680
we can bring off more

0:03:45.680,0:03:52.000
like everywhere that's a very cool

0:03:49.680,0:03:52.000
thought

0:03:56.000,0:04:00.480
next one is could this be used with

0:03:58.080,0:04:03.200
packages like smart parents that aim to

0:04:00.480,0:04:07.120
bring structural editing to

0:04:03.200,0:04:11.360
non-s expression based languages

0:04:07.120,0:04:14.720
yes that is actually one of the

0:04:11.360,0:04:17.280
intended use cases initially

0:04:14.720,0:04:18.880
it's definitely possible but it's just

0:04:17.280,0:04:29.840
that no one has

0:04:18.880,0:04:29.840
only started writing the integration yet

0:04:37.199,0:04:41.919
and next one

0:04:40.639,0:04:45.040
could you show the source that was

0:04:41.919,0:04:48.479
matched by the parser in the debug view

0:04:45.040,0:04:53.440
in addition to the grammar part matched

0:04:48.479,0:04:53.440
uh yeah that's actually um

0:04:54.960,0:04:59.280
on my to-do list but I haven't had time

0:04:57.759,0:05:02.560
for it yet

0:04:59.280,0:05:06.560
so uh if you go to the treesita

0:05:02.560,0:05:08.800
website it also has an

0:05:06.560,0:05:11.840
online playground where you can input

0:05:08.800,0:05:11.840
the code and see the

0:05:12.000,0:05:16.000
parse tree in real time and it's

0:05:14.400,0:05:19.360
actually

0:05:16.000,0:05:22.840
a lot more fancy than what we have in

0:05:19.360,0:05:25.919
imax currently so

0:05:22.840,0:05:27.120
yeah I just don't have time for it yes

0:05:25.919,0:05:30.240
so

0:05:27.120,0:05:30.240
some help here would be

0:05:30.320,0:05:41.730
very appreciated

0:05:38.700,0:05:41.730
[Music]

0:05:49.919,0:05:54.240
the next question is will it ever be

0:05:52.000,0:05:55.280
possible to write resetter grammars in a

0:05:54.240,0:05:59.520
lisp

0:05:55.280,0:05:59.520
or will javascript be required

0:06:00.560,0:06:05.280
yeah that is already answered in the

0:06:02.800,0:06:07.600
part so the

0:06:05.280,0:06:08.639
the transcript is actually just used as

0:06:07.600,0:06:12.160
a sort of

0:06:08.639,0:06:14.639
preprocessor so the

0:06:12.160,0:06:15.680
python generator actually works on the

0:06:14.639,0:06:19.280
on a json

0:06:15.680,0:06:20.240
structure so uh it's definitely possible

0:06:19.280,0:06:24.240
to replace

0:06:20.240,0:06:24.240
javascript with lists for this

0:06:29.039,0:06:32.160
how extensive will the compatibility

0:06:31.280,0:06:35.360
between

0:06:32.160,0:06:35.840
highlighting grammars for e-max and

0:06:35.360,0:06:41.039
those

0:06:35.840,0:06:41.039
for veeam nail view

0:06:44.560,0:06:51.680
so so right now the

0:06:48.720,0:06:52.000
nail vim and Emacs used a different set

0:06:51.680,0:06:55.440
of

0:06:52.000,0:06:59.520
the highlighting queries and

0:06:55.440,0:07:03.039
item probably uses another set of

0:06:59.520,0:07:04.960
patterns as well I think it makes sense

0:07:03.039,0:07:07.680
because

0:07:04.960,0:07:08.479
each editor has its own like existing

0:07:07.680,0:07:11.919
conventions

0:07:08.479,0:07:15.599
for syntax highlighting so

0:07:11.919,0:07:18.560
at least in the beginning I don't expect

0:07:15.599,0:07:21.520
there is any compatibility between

0:07:18.560,0:07:21.520
different editors

0:07:21.599,0:07:26.639
but I think in the long run it will be

0:07:27.280,0:07:31.360
would it better if there's some kind of

0:07:29.520,0:07:34.880
effort to

0:07:31.360,0:07:37.440
unify the at least provide the

0:07:34.880,0:07:39.759
most common patterns that should work

0:07:37.440,0:07:39.759
across

0:07:42.840,0:07:45.840
editors

0:07:51.759,0:07:55.280
next one is could there be a

0:07:53.520,0:07:57.919
standardized approach

0:07:55.280,0:08:00.319
to coding automatic refactoring in the

0:07:57.919,0:08:00.319
future

0:08:01.039,0:08:04.160
so that whichever language mode you're

0:08:02.639,0:08:12.960
using you could see many

0:08:04.160,0:08:16.400
available refactoring operations

0:08:12.960,0:08:18.639
I'm not sure about this because the

0:08:16.400,0:08:18.639
like

0:08:19.919,0:08:23.840
most of uh refactoring operations are

0:08:22.240,0:08:26.960
actually very

0:08:23.840,0:08:28.720
like highly specific to a language or at

0:08:26.960,0:08:32.800
least to class of

0:08:28.720,0:08:32.800
class of languages so

0:08:33.599,0:08:40.719
so so maybe it's not like uh one single

0:08:37.839,0:08:41.519
approach for all the languages but maybe

0:08:40.719,0:08:43.760
uh

0:08:41.519,0:08:44.959
one for object-oriented oriented

0:08:43.760,0:08:49.920
languages

0:08:44.959,0:08:49.920
one for lisp like language for example

0:08:50.160,0:08:55.839
maybe one for javascript and typestream

0:09:02.959,0:09:07.519
next question is uh I'm completely new

0:09:05.360,0:09:10.160
to trisita how do I use it

0:09:07.519,0:09:11.519
as an end user is there any easy example

0:09:10.160,0:09:14.000
config out there

0:09:11.519,0:09:15.440
the organizer otherwise that shows

0:09:14.000,0:09:18.959
standard usage

0:09:15.440,0:09:18.959
with whatever programming language

0:09:18.960,0:09:23.920
[Music]

0:09:20.480,0:09:23.920
yeah there's no um

0:09:27.600,0:09:32.000
uh actually that uh so the project has

0:09:30.880,0:09:36.399
the documentation

0:09:32.000,0:09:40.720
site but it's not very expensive yet

0:09:36.399,0:09:44.000
I think we need to add more examples

0:09:40.720,0:09:44.000
to the documentation

0:09:48.720,0:09:53.519
can language major mode authors start

0:09:51.200,0:09:56.240
taking advantage of this now

0:09:53.519,0:09:57.279
or is it intended to be used as a minor

0:09:56.240,0:10:00.399
mode

0:09:57.279,0:10:01.600
uh actually it's both so it's intended

0:10:00.399,0:10:04.480
to be used

0:10:01.600,0:10:05.920
as a minor mode but it's also intended

0:10:04.480,0:10:09.839
to

0:10:05.920,0:10:13.519
be depended on by the major mode

0:10:09.839,0:10:13.920
so basically it it wants to be a minor

0:10:13.519,0:10:17.200
mode

0:10:13.920,0:10:19.839
that is dependent on by the other

0:10:17.200,0:10:19.839
major modes

0:10:21.839,0:10:29.279
and by it here I mean the the base

0:10:25.680,0:10:29.279
minor mode tree system mode

0:10:30.839,0:10:37.120
so uh question

0:10:34.079,0:10:40.160
11 is it possible to use this

0:10:37.120,0:10:43.360
for refactoring tool

0:10:40.160,0:10:46.720
uh yeah but

0:10:43.360,0:10:47.680
um like for the kind of refactoring

0:10:46.720,0:10:52.079
inside uh

0:10:47.680,0:10:52.079
buffer it is uh

0:10:52.640,0:10:57.040
it's very doable right now but you need

0:10:55.040,0:11:01.120
to write some glue code

0:10:57.040,0:11:04.000
but for for the kind of more

0:11:01.120,0:11:04.399
extensive refactoring where you want to

0:11:04.000,0:11:09.120
touch

0:11:04.399,0:11:09.120
uh like all files in a project

0:11:09.279,0:11:12.839
there needs there needs to be some kind

0:11:11.440,0:11:15.920
of the project

0:11:12.839,0:11:18.399
and another project and uh

0:11:15.920,0:11:19.200
understanding of the language uh model

0:11:18.399,0:11:21.120
system

0:11:19.200,0:11:22.560
like how they are laid out in the file

0:11:21.120,0:11:24.480
system as well

0:11:22.560,0:11:26.240
and with that understanding that there

0:11:24.480,0:11:29.920
should be passing of

0:11:26.240,0:11:30.480
the files even files on the file system

0:11:29.920,0:11:34.000
that

0:11:30.480,0:11:37.760
are not yet loaded into Emacs

0:11:34.000,0:11:40.320
so that sounds like something more

0:11:37.760,0:11:40.320
a lot more

0:11:41.040,0:11:44.560
a lot more extensive

0:11:46.320,0:11:50.000
and it probably probably sounds like

0:11:49.519,0:11:52.160
something

0:11:50.000,0:11:54.560
something like an id in uh inside your

0:11:52.160,0:11:57.839
max already like a replacement for

0:11:54.560,0:11:57.839
for lsp

0:12:07.360,0:12:11.440
so next question is the that pop-up mx

0:12:10.480,0:12:14.480
window

0:12:11.440,0:12:14.480
how do you get that

0:12:15.200,0:12:20.320
is the custom hem code I wrote a long

0:12:18.720,0:12:24.800
time ago

0:12:20.320,0:12:26.480
but but right now the best way to

0:12:24.800,0:12:29.440
to have something like that is probably

0:12:26.480,0:12:33.200
the what is written here like uh

0:12:29.440,0:12:39.839
ham boss frame or iv spring

0:12:33.200,0:12:43.680
is a lot easier now

0:12:39.839,0:12:46.320
is there a folding mode for tree sitter

0:12:43.680,0:12:48.079
nowadays there's no folding mode for

0:12:46.320,0:12:52.000
three sitters yet

0:12:48.079,0:12:54.880
but uh

0:12:52.000,0:12:58.720
uh but I think it would better be better

0:12:54.880,0:12:58.720
if it's integrated with the

0:12:59.440,0:13:03.120
like current currently there are

0:13:02.079,0:13:04.880
multiple

0:13:03.120,0:13:07.200
I'm not sure they're moving forward

0:13:04.880,0:13:10.240
there are like code folding frameworks

0:13:07.200,0:13:12.800
inside imax already or some the

0:13:10.240,0:13:13.920
code showing packages like third party

0:13:12.800,0:13:15.680
packaging

0:13:13.920,0:13:17.680
and I think it's better to integrate

0:13:15.680,0:13:20.000
with these mods

0:13:17.680,0:13:22.560
rather than writing something new

0:13:20.000,0:13:22.560
entirely

0:13:32.399,0:13:36.639
are there any language major modes that

0:13:34.800,0:13:40.079
have integrated already

0:13:36.639,0:13:42.800
uh not yet

0:13:40.079,0:13:43.440
so the there was a proposed web assembly

0:13:42.800,0:13:46.839
mode

0:13:43.440,0:13:50.000
but it's a new major mode in terms of

0:13:46.839,0:13:52.880
existing major mode there is the

0:13:50.000,0:13:52.880
typescript mode

0:13:53.279,0:13:57.519
but they're only discussing about

0:13:55.600,0:14:02.079
integration

0:13:57.519,0:14:04.639
they're not integrated yet

0:14:02.079,0:14:05.360
I think I can try writing the

0:14:04.639,0:14:09.199
integration

0:14:05.360,0:14:11.839
sometimes next month

0:14:09.199,0:14:12.720
uh basically what they want right now is

0:14:11.839,0:14:16.160
the

0:14:12.720,0:14:19.199
syntax highlighting and handling

0:14:16.160,0:14:22.959
synthetic highlighting and

0:14:19.199,0:14:27.760
code indentation for tsx

0:14:22.959,0:14:31.839
which is the embedded react

0:14:27.760,0:14:31.839
syntax inside typescript

0:14:32.160,0:14:40.000
so it turns out passing these tests

0:14:36.399,0:14:40.000
is very troublesome so

0:14:40.639,0:14:47.040
so trees that would be a crystal would

0:14:43.920,0:14:47.040
be a lot of help there

0:14:49.920,0:14:59.839
is there any link to the slides yes

0:14:53.279,0:14:59.839
I'll post it in irc later

0:14:59.920,0:15:04.240
regarding imax integration we will

0:15:01.920,0:15:05.440
always need to be a foreign library or

0:15:04.240,0:15:09.920
can it be included

0:15:05.440,0:15:09.920
linked directly in compilation

0:15:10.839,0:15:17.600
uh if if this is about the

0:15:14.480,0:15:21.839
core library itself

0:15:17.600,0:15:23.440
then I think it's uh answered it in the

0:15:21.839,0:15:27.440
first question

0:15:23.440,0:15:29.920
right now is a right now it's a

0:15:27.440,0:15:30.959
dynamic model but in the long run it

0:15:29.920,0:15:34.000
will better if

0:15:30.959,0:15:39.839
it's included in core Emacs

0:15:34.000,0:15:41.360
for the language definitions themselves

0:15:39.839,0:15:43.279
it should be better if they are

0:15:41.360,0:15:46.639
distributed uh

0:15:43.279,0:15:49.199
separately like that right now so each

0:15:46.639,0:15:49.680
uh for each language there will be a

0:15:49.199,0:15:52.639
shared

0:15:49.680,0:15:55.839
library that will be loaded by the core

0:15:52.639,0:15:55.839
library at runtime

0:16:00.480,0:16:04.240
so the last question is the python mode

0:16:02.480,0:16:06.160
example is pretty good

0:16:04.240,0:16:07.600
is that something that one can use

0:16:06.160,0:16:11.759
already

0:16:07.600,0:16:11.759
yes I'm using it at work right now

0:16:12.320,0:16:17.360
I think that's all for that's all the

0:16:14.639,0:16:17.360
questions right

0:16:19.199,0:16:27.839
you are now unmuted yeah I think that's

0:16:23.440,0:16:30.399
all the questions on the pads so far um

0:16:27.839,0:16:32.399
so thank you but um there may be more

0:16:30.399,0:16:36.639
questions coming on irc

0:16:32.399,0:16:39.680
um I'll try to have a look

0:16:36.639,0:16:40.560
and we still have about 10 or 15 more

0:16:39.680,0:16:43.600
minutes so

0:16:40.560,0:16:46.880
um there's no rush to wrap up in case um

0:16:43.600,0:16:46.880
anyone has any more questions

0:16:48.160,0:16:51.360
uh yeah I just realized that uh I mixed

0:16:50.880,0:16:54.959
up the

0:16:51.360,0:16:56.000
video editing and I uh lost an entire

0:16:54.959,0:17:00.880
session on the

0:16:56.000,0:17:00.880
introduction to treesita oh

0:17:01.120,0:17:05.839
no worries

0:17:06.640,0:17:20.079
you are now muted

0:17:18.079,0:17:21.679
sounds like a perfect opportunity for

0:17:20.079,0:17:24.000
you to redo the introduction if you'd

0:17:21.679,0:17:24.000
like to

0:17:24.640,0:17:30.000
uh actually uh forgot a lot of that

0:17:30.799,0:17:35.760
and I'm with uh tired now so no I don't

0:17:33.760,0:17:39.200
think I can do it

0:17:35.760,0:17:43.520
it's uh 30 minutes until my bedtime

0:17:39.200,0:17:46.640
oh yeah yeah okay you are now unmuted

0:17:43.520,0:17:50.480
so in that case maybe we should

0:17:46.640,0:17:54.240
um we should let tona

0:17:50.480,0:17:56.960
get started going to bed and um and

0:17:54.240,0:17:57.840
I mean then I will figure out what to do

0:17:56.960,0:17:59.360
with the time

0:17:57.840,0:18:02.160
should we start the next talk early

0:17:59.360,0:18:05.360
since it's pre-recorded

0:18:02.160,0:18:07.919
um yeah we can do we can do that um

0:18:05.360,0:18:09.919
but um yeah tonight it you know right

0:18:07.919,0:18:10.480
now it's pretty late there um no worries

0:18:09.919,0:18:12.720
but

0:18:10.480,0:18:13.520
yeah if you know over the next few days

0:18:12.720,0:18:16.559
or weeks

0:18:13.520,0:18:20.240
if you would like to um you know

0:18:16.559,0:18:22.080
do a quick pre-recording or recording

0:18:20.240,0:18:24.320
to add the introduction and then stitch

0:18:22.080,0:18:26.559
it in with what you had already sent me

0:18:24.320,0:18:30.160
um by all means please do that and I

0:18:26.559,0:18:33.760
will upload the edited version

0:18:30.160,0:18:33.760
uh yeah yeah I'll try to do that

0:18:34.880,0:18:39.760
thank you yep thank you so much bye