blob: 0f0b2688ff1fe007b690e174b27029f4738a0379 (
plain) (
tree)
|
|
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
|
