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
