WEBVTT

00:00:00.960 --> 00:00:03.679
uh okay so the first question is is uh

00:00:03.679 --> 00:00:05.600
do you think that this package can be

00:00:05.600 --> 00:00:08.000
included into Emacs or

00:00:08.000 --> 00:00:12.320
uh empire uh

00:00:12.320 --> 00:00:15.360
I think uh it most definitely can is

00:00:15.360 --> 00:00:18.560
just a matter of paperwork but

00:00:18.560 --> 00:00:21.760
the reason I initially wanted to make it

00:00:21.760 --> 00:00:24.480
like a central package is that so that I

00:00:24.480 --> 00:00:25.039
can

00:00:25.039 --> 00:00:28.720
experiment with it more

00:00:28.720 --> 00:00:31.920
like have more freedom to experiment but

00:00:31.920 --> 00:00:34.320
eventually I think is a good candidate

00:00:34.320 --> 00:00:35.680
for inclusion into

00:00:35.680 --> 00:00:38.800
core

00:00:38.800 --> 00:00:41.200
and because because currently not in

00:00:41.200 --> 00:00:42.640
corey mass there are a couple of

00:00:42.640 --> 00:00:44.480
problems with it

00:00:44.480 --> 00:00:47.840
mostly in terms of performance

00:00:47.840 --> 00:00:50.960
for example like anytime we want to

00:00:50.960 --> 00:00:53.280
access the text in a buffer we need to

00:00:53.280 --> 00:00:54.160
make

00:00:54.160 --> 00:00:57.360
a copy of the text into a string

00:00:57.360 --> 00:01:00.480
and then right after reading from that

00:01:00.480 --> 00:01:03.520
text we need to free it right away and

00:01:03.520 --> 00:01:05.280
that results in a lot of garbage

00:01:05.280 --> 00:01:09.040
collection so it would be better

00:01:09.040 --> 00:01:11.920
either the treasure could be included in

00:01:11.920 --> 00:01:12.240
core

00:01:12.240 --> 00:01:15.680
imax or dynamic dynamic model support

00:01:15.680 --> 00:01:16.799
can be

00:01:16.799 --> 00:01:19.439
augmented with direct text access

00:01:19.439 --> 00:01:24.080
somehow

00:01:24.080 --> 00:01:26.400
so the second question is will release

00:01:26.400 --> 00:01:27.200
performance

00:01:27.200 --> 00:01:30.320
be more competitive with cce max

00:01:30.320 --> 00:01:33.040
enough so electricity in english is more

00:01:33.040 --> 00:01:35.670
attractive

00:01:35.670 --> 00:01:38.240
[Music]

00:01:38.240 --> 00:01:43.439
I think it's possible but uh yeah

00:01:43.439 --> 00:01:45.840
not sure about the amount of effort it

00:01:45.840 --> 00:01:46.799
can be

00:01:46.799 --> 00:01:52.960
multi-years effort and one thing that

00:01:52.960 --> 00:01:56.479
even though gce max can make uh

00:01:56.479 --> 00:02:00.719
it is fast enough there's

00:02:00.719 --> 00:02:03.119
there's one thing that it uh cannot have

00:02:03.119 --> 00:02:05.280
which is that because it's the lisp

00:02:05.280 --> 00:02:09.679
it needs the garage collector so

00:02:09.679 --> 00:02:12.480
we may experiment experience some kind

00:02:12.480 --> 00:02:14.000
of

00:02:14.000 --> 00:02:17.360
gcc post if we use live whereas the

00:02:17.360 --> 00:02:19.920
currently transistor is written in c

00:02:19.920 --> 00:02:28.400
so there's no such latency

00:02:28.400 --> 00:02:31.040
the next question is do you think three

00:02:31.040 --> 00:02:32.400
sister would be useful

00:02:32.400 --> 00:02:36.080
for all buffers I can imagine it being

00:02:36.080 --> 00:02:38.319
used to keep a post ast about an arc

00:02:38.319 --> 00:02:39.599
buffer

00:02:39.599 --> 00:02:42.560
light off element and update it in real

00:02:42.560 --> 00:02:43.920
time

00:02:43.920 --> 00:02:46.239
yeah actually this is a very interesting

00:02:46.239 --> 00:02:47.760
idea

00:02:47.760 --> 00:02:50.800
I saw someone started

00:02:50.800 --> 00:02:53.760
resistor grammar for all already I don't

00:02:53.760 --> 00:02:55.120
have a link right now but

00:02:55.120 --> 00:02:58.159
I can look for it

00:02:58.159 --> 00:03:01.040
I'll try looking for it and put the link

00:03:01.040 --> 00:03:01.680
in

00:03:01.680 --> 00:03:09.599
here later

00:03:09.599 --> 00:03:13.280
yeah yes someone has written here the uh

00:03:13.280 --> 00:03:15.519
and the biggest problem with uh right

00:03:15.519 --> 00:03:17.040
now is that it doesn't have

00:03:17.040 --> 00:03:21.360
formal grammar so

00:03:21.360 --> 00:03:22.380
so the effort

00:03:22.380 --> 00:03:24.400
[Applause]

00:03:24.400 --> 00:03:27.120
be quite big I think but but once we

00:03:27.120 --> 00:03:28.799
have that because the

00:03:28.799 --> 00:03:31.519
tree sitter can be run on the web as

00:03:31.519 --> 00:03:34.239
well

00:03:34.239 --> 00:03:37.440
we can on the web and in many other

00:03:37.440 --> 00:03:38.080
places

00:03:38.080 --> 00:03:40.720
if we have a grammar for a traditional

00:03:40.720 --> 00:03:41.840
grammar for all

00:03:41.840 --> 00:03:45.680
we can bring off more

00:03:45.680 --> 00:03:49.680
like everywhere that's a very cool

00:03:49.680 --> 00:03:56.000
thought

00:03:56.000 --> 00:03:58.080
next one is could this be used with

00:03:58.080 --> 00:04:00.480
packages like smart parents that aim to

00:04:00.480 --> 00:04:03.200
bring structural editing to

00:04:03.200 --> 00:04:07.120
non-s expression based languages

00:04:07.120 --> 00:04:11.360
yes that is actually one of the

00:04:11.360 --> 00:04:14.720
intended use cases initially

00:04:14.720 --> 00:04:17.280
it's definitely possible but it's just

00:04:17.280 --> 00:04:18.880
that no one has

00:04:18.880 --> 00:04:37.199
only started writing the integration yet

00:04:37.199 --> 00:04:40.639
and next one

00:04:40.639 --> 00:04:41.919
could you show the source that was

00:04:41.919 --> 00:04:45.040
matched by the parser in the debug view

00:04:45.040 --> 00:04:48.479
in addition to the grammar part matched

00:04:48.479 --> 00:04:54.960
uh yeah that's actually um

00:04:54.960 --> 00:04:57.759
on my to-do list but I haven't had time

00:04:57.759 --> 00:04:59.280
for it yet

00:04:59.280 --> 00:05:02.560
so uh if you go to the treesita

00:05:02.560 --> 00:05:06.560
website it also has an

00:05:06.560 --> 00:05:08.800
online playground where you can input

00:05:08.800 --> 00:05:12.000
the code and see the

00:05:12.000 --> 00:05:14.400
parse tree in real time and it's

00:05:14.400 --> 00:05:16.000
actually

00:05:16.000 --> 00:05:19.360
a lot more fancy than what we have in

00:05:19.360 --> 00:05:22.840
imax currently so

00:05:22.840 --> 00:05:25.919
yeah I just don't have time for it yes

00:05:25.919 --> 00:05:27.120
so

00:05:27.120 --> 00:05:30.320
some help here would be

00:05:30.320 --> 00:05:38.700
very appreciated

00:05:38.700 --> 00:05:49.919
[Music]

00:05:49.919 --> 00:05:52.000
the next question is will it ever be

00:05:52.000 --> 00:05:54.240
possible to write resetter grammars in a

00:05:54.240 --> 00:05:55.280
lisp

00:05:55.280 --> 00:06:00.560
or will javascript be required

00:06:00.560 --> 00:06:02.800
yeah that is already answered in the

00:06:02.800 --> 00:06:05.280
part so the

00:06:05.280 --> 00:06:07.600
the transcript is actually just used as

00:06:07.600 --> 00:06:08.639
a sort of

00:06:08.639 --> 00:06:12.160
preprocessor so the

00:06:12.160 --> 00:06:14.639
python generator actually works on the

00:06:14.639 --> 00:06:15.680
on a json

00:06:15.680 --> 00:06:19.280
structure so uh it's definitely possible

00:06:19.280 --> 00:06:20.240
to replace

00:06:20.240 --> 00:06:29.039
javascript with lists for this

00:06:29.039 --> 00:06:31.280
how extensive will the compatibility

00:06:31.280 --> 00:06:32.160
between

00:06:32.160 --> 00:06:35.360
highlighting grammars for e-max and

00:06:35.360 --> 00:06:35.840
those

00:06:35.840 --> 00:06:44.560
for veeam nail view

00:06:44.560 --> 00:06:48.720
so so right now the

00:06:48.720 --> 00:06:51.680
nail vim and Emacs used a different set

00:06:51.680 --> 00:06:52.000
of

00:06:52.000 --> 00:06:55.440
the highlighting queries and

00:06:55.440 --> 00:06:59.520
item probably uses another set of

00:06:59.520 --> 00:07:03.039
patterns as well I think it makes sense

00:07:03.039 --> 00:07:04.960
because

00:07:04.960 --> 00:07:07.680
each editor has its own like existing

00:07:07.680 --> 00:07:08.479
conventions

00:07:08.479 --> 00:07:11.919
for syntax highlighting so

00:07:11.919 --> 00:07:15.599
at least in the beginning I don't expect

00:07:15.599 --> 00:07:18.560
there is any compatibility between

00:07:18.560 --> 00:07:21.599
different editors

00:07:21.599 --> 00:07:27.280
but I think in the long run it will be

00:07:27.280 --> 00:07:29.520
would it better if there's some kind of

00:07:29.520 --> 00:07:31.360
effort to

00:07:31.360 --> 00:07:34.880
unify the at least provide the

00:07:34.880 --> 00:07:37.440
most common patterns that should work

00:07:37.440 --> 00:07:42.840
across

00:07:42.840 --> 00:07:51.759
editors

00:07:51.759 --> 00:07:53.520
next one is could there be a

00:07:53.520 --> 00:07:55.280
standardized approach

00:07:55.280 --> 00:07:57.919
to coding automatic refactoring in the

00:07:57.919 --> 00:08:01.039
future

00:08:01.039 --> 00:08:02.639
so that whichever language mode you're

00:08:02.639 --> 00:08:04.160
using you could see many

00:08:04.160 --> 00:08:12.960
available refactoring operations

00:08:12.960 --> 00:08:16.400
I'm not sure about this because the

00:08:16.400 --> 00:08:19.919
like

00:08:19.919 --> 00:08:22.240
most of uh refactoring operations are

00:08:22.240 --> 00:08:23.840
actually very

00:08:23.840 --> 00:08:26.960
like highly specific to a language or at

00:08:26.960 --> 00:08:28.720
least to class of

00:08:28.720 --> 00:08:33.599
class of languages so

00:08:33.599 --> 00:08:37.839
so so maybe it's not like uh one single

00:08:37.839 --> 00:08:40.719
approach for all the languages but maybe

00:08:40.719 --> 00:08:41.519
uh

00:08:41.519 --> 00:08:43.760
one for object-oriented oriented

00:08:43.760 --> 00:08:44.959
languages

00:08:44.959 --> 00:08:50.160
one for lisp like language for example

00:08:50.160 --> 00:09:02.959
maybe one for javascript and typestream

00:09:02.959 --> 00:09:05.360
next question is uh I'm completely new

00:09:05.360 --> 00:09:07.519
to trisita how do I use it

00:09:07.519 --> 00:09:10.160
as an end user is there any easy example

00:09:10.160 --> 00:09:11.519
config out there

00:09:11.519 --> 00:09:14.000
the organizer otherwise that shows

00:09:14.000 --> 00:09:15.440
standard usage

00:09:15.440 --> 00:09:18.960
with whatever programming language

00:09:18.960 --> 00:09:20.480
[Music]

00:09:20.480 --> 00:09:27.600
yeah there's no um

00:09:27.600 --> 00:09:30.880
uh actually that uh so the project has

00:09:30.880 --> 00:09:32.000
the documentation

00:09:32.000 --> 00:09:36.399
site but it's not very expensive yet

00:09:36.399 --> 00:09:40.720
I think we need to add more examples

00:09:40.720 --> 00:09:48.720
to the documentation

00:09:48.720 --> 00:09:51.200
can language major mode authors start

00:09:51.200 --> 00:09:53.519
taking advantage of this now

00:09:53.519 --> 00:09:56.240
or is it intended to be used as a minor

00:09:56.240 --> 00:09:57.279
mode

00:09:57.279 --> 00:10:00.399
uh actually it's both so it's intended

00:10:00.399 --> 00:10:01.600
to be used

00:10:01.600 --> 00:10:04.480
as a minor mode but it's also intended

00:10:04.480 --> 00:10:05.920
to

00:10:05.920 --> 00:10:09.839
be depended on by the major mode

00:10:09.839 --> 00:10:13.519
so basically it it wants to be a minor

00:10:13.519 --> 00:10:13.920
mode

00:10:13.920 --> 00:10:17.200
that is dependent on by the other

00:10:17.200 --> 00:10:21.839
major modes

00:10:21.839 --> 00:10:25.680
and by it here I mean the the base

00:10:25.680 --> 00:10:30.839
minor mode tree system mode

00:10:30.839 --> 00:10:34.079
so uh question

00:10:34.079 --> 00:10:37.120
11 is it possible to use this

00:10:37.120 --> 00:10:40.160
for refactoring tool

00:10:40.160 --> 00:10:43.360
uh yeah but

00:10:43.360 --> 00:10:46.720
um like for the kind of refactoring

00:10:46.720 --> 00:10:47.680
inside uh

00:10:47.680 --> 00:10:52.640
buffer it is uh

00:10:52.640 --> 00:10:55.040
it's very doable right now but you need

00:10:55.040 --> 00:10:57.040
to write some glue code

00:10:57.040 --> 00:11:01.120
but for for the kind of more

00:11:01.120 --> 00:11:04.000
extensive refactoring where you want to

00:11:04.000 --> 00:11:04.399
touch

00:11:04.399 --> 00:11:09.279
uh like all files in a project

00:11:09.279 --> 00:11:11.440
there needs there needs to be some kind

00:11:11.440 --> 00:11:12.839
of the project

00:11:12.839 --> 00:11:15.920
and another project and uh

00:11:15.920 --> 00:11:18.399
understanding of the language uh model

00:11:18.399 --> 00:11:19.200
system

00:11:19.200 --> 00:11:21.120
like how they are laid out in the file

00:11:21.120 --> 00:11:22.560
system as well

00:11:22.560 --> 00:11:24.480
and with that understanding that there

00:11:24.480 --> 00:11:26.240
should be passing of

00:11:26.240 --> 00:11:29.920
the files even files on the file system

00:11:29.920 --> 00:11:30.480
that

00:11:30.480 --> 00:11:34.000
are not yet loaded into Emacs

00:11:34.000 --> 00:11:37.760
so that sounds like something more

00:11:37.760 --> 00:11:41.040
a lot more

00:11:41.040 --> 00:11:46.320
a lot more extensive

00:11:46.320 --> 00:11:49.519
and it probably probably sounds like

00:11:49.519 --> 00:11:50.000
something

00:11:50.000 --> 00:11:52.160
something like an id in uh inside your

00:11:52.160 --> 00:11:54.560
max already like a replacement for

00:11:54.560 --> 00:12:07.360
for lsp

00:12:07.360 --> 00:12:10.480
so next question is the that pop-up mx

00:12:10.480 --> 00:12:11.440
window

00:12:11.440 --> 00:12:15.200
how do you get that

00:12:15.200 --> 00:12:18.720
is the custom hem code I wrote a long

00:12:18.720 --> 00:12:20.320
time ago

00:12:20.320 --> 00:12:24.800
but but right now the best way to

00:12:24.800 --> 00:12:26.480
to have something like that is probably

00:12:26.480 --> 00:12:29.440
the what is written here like uh

00:12:29.440 --> 00:12:33.200
ham boss frame or iv spring

00:12:33.200 --> 00:12:39.839
is a lot easier now

00:12:39.839 --> 00:12:43.680
is there a folding mode for tree sitter

00:12:43.680 --> 00:12:46.320
nowadays there's no folding mode for

00:12:46.320 --> 00:12:48.079
three sitters yet

00:12:48.079 --> 00:12:52.000
but uh

00:12:52.000 --> 00:12:54.880
uh but I think it would better be better

00:12:54.880 --> 00:12:59.440
if it's integrated with the

00:12:59.440 --> 00:13:02.079
like current currently there are

00:13:02.079 --> 00:13:03.120
multiple

00:13:03.120 --> 00:13:04.880
I'm not sure they're moving forward

00:13:04.880 --> 00:13:07.200
there are like code folding frameworks

00:13:07.200 --> 00:13:10.240
inside imax already or some the

00:13:10.240 --> 00:13:12.800
code showing packages like third party

00:13:12.800 --> 00:13:13.920
packaging

00:13:13.920 --> 00:13:15.680
and I think it's better to integrate

00:13:15.680 --> 00:13:17.680
with these mods

00:13:17.680 --> 00:13:20.000
rather than writing something new

00:13:20.000 --> 00:13:32.399
entirely

00:13:32.399 --> 00:13:34.800
are there any language major modes that

00:13:34.800 --> 00:13:36.639
have integrated already

00:13:36.639 --> 00:13:40.079
uh not yet

00:13:40.079 --> 00:13:42.800
so the there was a proposed web assembly

00:13:42.800 --> 00:13:43.440
mode

00:13:43.440 --> 00:13:46.839
but it's a new major mode in terms of

00:13:46.839 --> 00:13:50.000
existing major mode there is the

00:13:50.000 --> 00:13:53.279
typescript mode

00:13:53.279 --> 00:13:55.600
but they're only discussing about

00:13:55.600 --> 00:13:57.519
integration

00:13:57.519 --> 00:14:02.079
they're not integrated yet

00:14:02.079 --> 00:14:04.639
I think I can try writing the

00:14:04.639 --> 00:14:05.360
integration

00:14:05.360 --> 00:14:09.199
sometimes next month

00:14:09.199 --> 00:14:11.839
uh basically what they want right now is

00:14:11.839 --> 00:14:12.720
the

00:14:12.720 --> 00:14:16.160
syntax highlighting and handling

00:14:16.160 --> 00:14:19.199
synthetic highlighting and

00:14:19.199 --> 00:14:22.959
code indentation for tsx

00:14:22.959 --> 00:14:27.760
which is the embedded react

00:14:27.760 --> 00:14:32.160
syntax inside typescript

00:14:32.160 --> 00:14:36.399
so it turns out passing these tests

00:14:36.399 --> 00:14:40.639
is very troublesome so

00:14:40.639 --> 00:14:43.920
so trees that would be a crystal would

00:14:43.920 --> 00:14:49.920
be a lot of help there

00:14:49.920 --> 00:14:53.279
is there any link to the slides yes

00:14:53.279 --> 00:14:59.920
I'll post it in irc later

00:14:59.920 --> 00:15:01.920
regarding imax integration we will

00:15:01.920 --> 00:15:04.240
always need to be a foreign library or

00:15:04.240 --> 00:15:05.440
can it be included

00:15:05.440 --> 00:15:10.839
linked directly in compilation

00:15:10.839 --> 00:15:14.480
uh if if this is about the

00:15:14.480 --> 00:15:17.600
core library itself

00:15:17.600 --> 00:15:21.839
then I think it's uh answered it in the

00:15:21.839 --> 00:15:23.440
first question

00:15:23.440 --> 00:15:27.440
right now is a right now it's a

00:15:27.440 --> 00:15:29.920
dynamic model but in the long run it

00:15:29.920 --> 00:15:30.959
will better if

00:15:30.959 --> 00:15:34.000
it's included in core Emacs

00:15:34.000 --> 00:15:39.839
for the language definitions themselves

00:15:39.839 --> 00:15:41.360
it should be better if they are

00:15:41.360 --> 00:15:43.279
distributed uh

00:15:43.279 --> 00:15:46.639
separately like that right now so each

00:15:46.639 --> 00:15:49.199
uh for each language there will be a

00:15:49.199 --> 00:15:49.680
shared

00:15:49.680 --> 00:15:52.639
library that will be loaded by the core

00:15:52.639 --> 00:16:00.480
library at runtime

00:16:00.480 --> 00:16:02.480
so the last question is the python mode

00:16:02.480 --> 00:16:04.240
example is pretty good

00:16:04.240 --> 00:16:06.160
is that something that one can use

00:16:06.160 --> 00:16:07.600
already

00:16:07.600 --> 00:16:12.320
yes I'm using it at work right now

00:16:12.320 --> 00:16:14.639
I think that's all for that's all the

00:16:14.639 --> 00:16:19.199
questions right

00:16:19.199 --> 00:16:23.440
you are now unmuted yeah I think that's

00:16:23.440 --> 00:16:27.839
all the questions on the pads so far um

00:16:27.839 --> 00:16:30.399
so thank you but um there may be more

00:16:30.399 --> 00:16:32.399
questions coming on irc

00:16:32.399 --> 00:16:36.639
um I'll try to have a look

00:16:36.639 --> 00:16:39.680
and we still have about 10 or 15 more

00:16:39.680 --> 00:16:40.560
minutes so

00:16:40.560 --> 00:16:43.600
um there's no rush to wrap up in case um

00:16:43.600 --> 00:16:48.160
anyone has any more questions

00:16:48.160 --> 00:16:50.880
uh yeah I just realized that uh I mixed

00:16:50.880 --> 00:16:51.360
up the

00:16:51.360 --> 00:16:54.959
video editing and I uh lost an entire

00:16:54.959 --> 00:16:56.000
session on the

00:16:56.000 --> 00:17:01.120
introduction to treesita oh

00:17:01.120 --> 00:17:06.640
no worries

00:17:06.640 --> 00:17:18.079
you are now muted

00:17:18.079 --> 00:17:20.079
sounds like a perfect opportunity for

00:17:20.079 --> 00:17:21.679
you to redo the introduction if you'd

00:17:21.679 --> 00:17:24.640
like to

00:17:24.640 --> 00:17:30.799
uh actually uh forgot a lot of that

00:17:30.799 --> 00:17:33.760
and I'm with uh tired now so no I don't

00:17:33.760 --> 00:17:35.760
think I can do it

00:17:35.760 --> 00:17:39.200
it's uh 30 minutes until my bedtime

00:17:39.200 --> 00:17:43.520
oh yeah yeah okay you are now unmuted

00:17:43.520 --> 00:17:46.640
so in that case maybe we should

00:17:46.640 --> 00:17:50.480
um we should let tona

00:17:50.480 --> 00:17:54.240
get started going to bed and um and

00:17:54.240 --> 00:17:56.960
I mean then I will figure out what to do

00:17:56.960 --> 00:17:57.840
with the time

00:17:57.840 --> 00:17:59.360
should we start the next talk early

00:17:59.360 --> 00:18:02.160
since it's pre-recorded

00:18:02.160 --> 00:18:05.360
um yeah we can do we can do that um

00:18:05.360 --> 00:18:07.919
but um yeah tonight it you know right

00:18:07.919 --> 00:18:09.919
now it's pretty late there um no worries

00:18:09.919 --> 00:18:10.480
but

00:18:10.480 --> 00:18:12.720
yeah if you know over the next few days

00:18:12.720 --> 00:18:13.520
or weeks

00:18:13.520 --> 00:18:16.559
if you would like to um you know

00:18:16.559 --> 00:18:20.240
do a quick pre-recording or recording

00:18:20.240 --> 00:18:22.080
to add the introduction and then stitch

00:18:22.080 --> 00:18:24.320
it in with what you had already sent me

00:18:24.320 --> 00:18:26.559
um by all means please do that and I

00:18:26.559 --> 00:18:30.160
will upload the edited version

00:18:30.160 --> 00:18:34.880
uh yeah yeah I'll try to do that

00:18:34.880 --> 00:18:39.760
thank you yep thank you so much bye