path: root/2022/captions/emacsconf-2022-lspbridge--lspbridge-a-smooth-as-butter-asynchronous-lsp-client--andy-stewart-matthew-zeng--main.vtt

WEBVTT captioned by matthew

NOTE Opening

00:00:00.000 --> 00:00:04.639
Good morning folks, I'm Matthew.

00:00:04.640 --> 00:00:07.399
Welcome to another year of EmacsConf.

00:00:07.400 --> 00:00:10.319
It's looking fantastic this year.

00:00:10.320 --> 00:00:13.559
Firstly, I have to apologize for my voice

00:00:13.560 --> 00:00:15.879
and occasional cough today.

00:00:15.880 --> 00:00:18.039
I am currently recovering from a cold,

00:00:18.040 --> 00:00:21.159
hopefully it's not Covid or flu,

00:00:21.160 --> 00:00:24.719
so please bear with me today.

00:00:24.720 --> 00:00:27.919
Actually, this talk was supposed to be brought to you

00:00:27.920 --> 00:00:31.559
by Manatee Lazycat, the author of lsp-bridge.

00:00:31.560 --> 00:00:36.079
But verbal English isn't Lazycat's strongest skill,

00:00:36.080 --> 00:00:38.599
and we are good friends as we maintain

00:00:38.600 --> 00:00:40.999
the Emacs Application Framework together,

00:00:41.000 --> 00:00:45.999
so here I am today presenting to you this package.

00:00:46.000 --> 00:00:48.479
Welcome to my talk on lsp-bridge:

00:00:48.480 --> 00:00:50.320
a smooth-as-butter asynchronous LSP client.

NOTE What is LSP?

00:00:50.321 --> 00:00:57.200
What is LSP?

00:00:57.201 --> 00:01:01.159
The first question is, what is LSP?

00:01:01.160 --> 00:01:03.199
For anyone who doesn't know here,

00:01:03.200 --> 00:01:06.799
LSP stands for Language Server Protocol,

00:01:06.800 --> 00:01:09.719
it is a set of protocols defined by Microsoft

00:01:09.720 --> 00:01:13.399
that provides smart features like autocomplete,

00:01:13.400 --> 00:01:17.599
go to definition, documentation, etc.,

00:01:17.600 --> 00:01:23.439
that can be implemented across different editors and IDEs.

00:01:23.440 --> 00:01:25.559
It was initially created

00:01:25.560 --> 00:01:28.399
for their Visual Studio Code product,

00:01:28.400 --> 00:01:33.919
then publically shared with everyone.

00:01:33.920 --> 00:01:35.999
So there are language servers out there

00:01:36.000 --> 00:01:38.119
that implemented this procotol,

00:01:38.120 --> 00:01:41.239
and editors need to implement the same procotols

00:01:41.240 --> 00:01:43.119
to talk to the language servers

00:01:43.120 --> 00:01:46.799
in order to retrieve necessary information.

00:01:46.800 --> 00:01:53.159
Emacs has 2 LSP clients already, the lsp-mode and eglot,

00:01:53.160 --> 00:01:57.319
both implemented the protocols and both are very good.

NOTE Why another LSP client?

00:02:00.440 --> 00:02:03.199
Now comes to the second question, of course,

00:02:03.200 --> 00:02:09.519
given lsp-mode and eglot, why another LSP client?

00:02:09.520 --> 00:02:12.359
I used to use lsp-mode all the time,

00:02:12.360 --> 00:02:15.999
I have to say I really appreciate Ivan Yonchovski

00:02:16.000 --> 00:02:20.159
and the team's efforts. Also, I'd like to congratuate eglot

00:02:20.160 --> 00:02:27.439
for making into Emacs 29! These are fantastic packages,

00:02:27.440 --> 00:02:30.999
they are very mature and robust.

NOTE

00:02:31.000 --> 00:02:31.000
However, with all due respect, both of the implementation

00:02:35.120 --> 00:02:36.719
are fundamentally limited

00:02:36.720 --> 00:02:39.639
by the single-threaded nature of Emacs,

00:02:39.640 --> 00:02:43.639
it is neither the fault of lsp-mode nor eglot.

NOTE

00:02:46.000 --> 00:02:47.959
Although in recent years there have been

00:02:47.960 --> 00:02:51.799
improvements to Emacs core such as native JSON support,

00:02:51.800 --> 00:02:55.319
there are still scenarios where Emacs clog

00:02:55.320 --> 00:02:59.359
for a brief second when processing large amounts of data,

00:02:59.360 --> 00:03:03.399
as Emacs is processing everything in the single thread.

00:03:03.400 --> 00:03:08.439
This problem is especially apparent in some LSP servers

00:03:08.440 --> 00:03:11.839
that feeds in tens of thousands of JSON data

00:03:11.840 --> 00:03:15.199
with every single key press.

NOTE

00:03:15.200 --> 00:03:17.559
Additionally, the large amount of data

00:03:17.560 --> 00:03:21.279
sent by the LSP server, such as the completion candidates,

00:03:21.280 --> 00:03:23.959
the diagnostics and documentation,

00:03:23.960 --> 00:03:27.359
they are temporarily stored in the Emacs memory,

00:03:27.360 --> 00:03:31.159
which will trigger garbage collection very frequently,

00:03:31.160 --> 00:03:34.159
this also causes stuttering user experience.

00:03:34.160 --> 00:03:37.279
Increasing the gc-cons-threshold helps,

00:03:37.280 --> 00:03:43.759
but doesn't eliminate the problem.

NOTE

00:03:43.760 --> 00:03:45.559
For something like the LSP,

00:03:45.560 --> 00:03:48.319
the language servers need time to compute,

00:03:48.320 --> 00:03:52.359
and Emacs needs capacity to process and filter

00:03:52.360 --> 00:03:55.799
all the data coming from the language servers.

00:03:55.800 --> 00:03:59.399
A large codebase project with a slow language server

00:03:59.400 --> 00:04:02.439
that sends tens of thousands of JSON

00:04:02.440 --> 00:04:06.519
will significantly increase the time needed to process it,

00:04:06.520 --> 00:04:08.079
when we don't have a multi-thread,

00:04:08.080 --> 00:04:12.719
the single thread originally allocated for perhaps,

00:04:12.720 --> 00:04:17.279
handling user input will be used to process all the data,

00:04:17.280 --> 00:04:22.719
and don't even talk about the garbage collection along the way.

NOTE

00:04:22.720 --> 00:04:26.239
The unfortunate truth is that the size of the codebase

00:04:26.240 --> 00:04:28.919
and the efficiency of the language server

00:04:28.920 --> 00:04:31.759
is completely out of Emacs' control,

00:04:31.760 --> 00:04:38.519
it is also out of both the lsp-mode and eglot's control.

NOTE

00:04:38.520 --> 00:04:40.279
If there's an LSP client

00:04:40.280 --> 00:04:42.279
that can completely eliminate stuttering

00:04:42.280 --> 00:04:44.999
and provide a seamless feedback,

00:04:45.000 --> 00:04:50.279
that would be great, isn't it?

NOTE What is seamless input feedback?

00:04:50.280 --> 00:04:53.839
However, we're vaguely talking about speed right now,

00:04:53.840 --> 00:04:56.399
what is considered fast?

00:04:56.400 --> 00:04:58.359
What is considered seamless?

00:04:58.360 --> 00:05:01.479
What we really mean when we say

00:05:01.480 --> 00:05:05.239
the current LSP implementation is slow?

00:05:05.240 --> 00:05:12.559
Let's first look at the problem fundamentally.

NOTE

00:05:12.560 --> 00:05:17.679
We interact with Emacs through a keyboard,

00:05:17.680 --> 00:05:22.719
so what we perceive as a fast and smooth feedback

00:05:22.720 --> 00:05:25.999
completely depends on how long it takes

00:05:26.000 --> 00:05:29.359
for a keyboard input to display on the Emacs buffer.

00:05:29.360 --> 00:05:32.919
From a pure graphical perspective,

00:05:32.920 --> 00:05:36.519
we need a minimum of 24 frames per second,

00:05:36.520 --> 00:05:39.079
the standard in the media industry,

00:05:39.080 --> 00:05:42.359
for us humans to perceive something as seamless.

00:05:42.360 --> 00:05:46.999
Say we need 25 frames per second, this means,

00:05:47.000 --> 00:05:50.399
if we divide 1000 milliseconds by 25,

00:05:50.400 --> 00:05:54.759
we only have approximately 40 millisecond window

00:05:54.760 --> 00:05:57.919
for the response time to spare.

00:05:57.920 --> 00:06:01.679
Even if we relax the constraint a bit more,

00:06:01.680 --> 00:06:06.679
on average a typist takes about 100 to 200 milliseconds

00:06:06.680 --> 00:06:09.159
between typing each character,

00:06:09.160 --> 00:06:12.599
so as long as we see a response within this timeframe,

00:06:12.600 --> 00:06:19.559
it is tolerable. However, using a slow language server

00:06:19.560 --> 00:06:22.279
on a large codebase easily exceeds

00:06:22.280 --> 00:06:24.679
the hundred millisecond mark,

00:06:24.680 --> 00:06:27.479
and sometimes takes more than 200 milliseconds,

00:06:27.480 --> 00:06:32.039
and inevitably will cause an inconsistent delay

00:06:32.040 --> 00:06:33.199
for the end user.

NOTE

00:06:33.200 --> 00:06:37.959
At this point, someone might want to point out

00:06:37.960 --> 00:06:41.079
that nobody is gonna type at the maximum pace all the time.

00:06:41.080 --> 00:06:45.039
That's right, frankly speaking most of my time

00:06:45.040 --> 00:06:47.639
spent at programming is not writing code,

00:06:47.640 --> 00:06:49.039
but staring at the screen

00:06:49.040 --> 00:06:51.279
thinking about how to write the code.

00:06:51.280 --> 00:06:55.599
However, when we do actually type,

00:06:55.600 --> 00:07:00.359
maybe only a sentence, a variable name, a keyword,

00:07:00.360 --> 00:07:03.039
or just performing keybinding shortcuts,

00:07:03.040 --> 00:07:08.479
that's when we want to see our input feedback immediately.

00:07:08.480 --> 00:07:10.479
We've already spend so much time

00:07:10.480 --> 00:07:12.159
thinking about how to write,

00:07:12.160 --> 00:07:16.479
we don't want to waste any more time waiting for Emacs

00:07:16.480 --> 00:07:19.559
to process and show us what we've written

00:07:19.560 --> 00:07:27.679
half a second ago. Otherwise the frustration will build up.

NOTE EAF showed a possibility

00:07:28.400 --> 00:07:31.999
In the past two years of EmacsConf, I've talked about

00:07:32.000 --> 00:07:35.399
the Emacs Application Framework, a project that extended

00:07:35.400 --> 00:07:39.839
Emacs Lisp to Python, Qt and JavaScript ecosystems.

00:07:39.840 --> 00:07:43.759
The EAF project specializes in improving

00:07:43.760 --> 00:07:47.439
the graphical and multimedia capabilities of Emacs

00:07:47.440 --> 00:07:51.759
through other languages, it was a great success.

00:07:51.760 --> 00:07:55.759
It demonstrated the endless possibilities of Emacs

00:07:55.760 --> 00:08:00.159
by embracing the strengths in other ecosystems.

00:08:00.160 --> 00:08:04.239
If anyone is interested for more information on EAF,

00:08:04.240 --> 00:08:08.519
please see the EAF repo and refer to my talks

00:08:08.520 --> 00:08:12.959
from EmacsConf2020 and 2021.

00:08:12.960 --> 00:08:12.960


00:08:12.960 --> 00:08:16.239
The EAF project was created by Manatee Lazycat as well,

00:08:16.240 --> 00:08:19.999
so he thought if there is a way to design

00:08:20.000 --> 00:08:22.759
an LSP client similar to EAF

00:08:22.760 --> 00:08:25.759
that takes the advantage of Python's multi-threading,

00:08:25.760 --> 00:08:27.839
it will be able to solve our problem.

00:08:27.840 --> 00:08:32.399
Conveniently EAF had already done most of the ground work

00:08:32.400 --> 00:08:34.359
and demonstrated the possibility

00:08:34.360 --> 00:08:42.159
of cooperating Elisp and Python using the Emacs RPC effectively.

NOTE LSP Bridge Objectives

00:08:42.160 --> 00:08:45.039
LSP Bridge has several goals in mind.

00:08:45.040 --> 00:08:50.159
Firstly, performance is the number one priority.

00:08:50.160 --> 00:08:55.839
Secondly, use Python multi-threading to bypass

00:08:55.840 --> 00:08:59.239
the aforementioned bottlenecks of a single-threaded Emacs.

00:08:59.240 --> 00:09:04.519
Thirdly, provide a simple solution that requires

00:09:04.520 --> 00:09:07.519
minimal setup for someone who just wants to have

00:09:07.520 --> 00:09:10.079
a fast autocomplete system in Emacs.

00:09:10.080 --> 00:09:15.999
This means, LSP Bridge does not intend

00:09:16.000 --> 00:09:21.439
and will not implement the entire LSP protocol,

00:09:21.440 --> 00:09:23.639
which is a vastly different approach

00:09:23.640 --> 00:09:25.759
than a solution like lsp-mode,

00:09:25.760 --> 00:09:28.479
we do not want to compete this way.

00:09:28.480 --> 00:09:33.559
We also believe some of the LSP Protocol features

00:09:33.560 --> 00:09:37.759
are unnecessary, or we already have better solutions

00:09:37.760 --> 00:09:38.959
in the Emacs ecosystem,

00:09:38.960 --> 00:09:42.679
such as tree-sitter for syntax highlighting.

00:09:42.680 --> 00:09:44.959
So we will not reinvent the wheel.

00:09:44.960 --> 00:09:50.279
Ultimately, we want to provide the fastest, butter-smooth

00:09:50.280 --> 00:09:53.679
and performant LSP client out of the box.

NOTE Design.

00:09:53.680 --> 00:09:54.560
Design.

00:09:54.561 --> 00:10:01.239
Now let's look at the design architecture diagram.

00:10:01.240 --> 00:10:04.639
As you can see, it is split into

00:10:04.640 --> 00:10:07.079
the top half and bottom half.

00:10:07.080 --> 00:10:10.559
The top is the design for a single file model,

00:10:10.560 --> 00:10:13.359
and the bottom half is for project model.

00:10:13.360 --> 00:10:18.159
We make this distinction because we don't want a new user

00:10:18.160 --> 00:10:22.599
to be troubled on choosing a project root directory

00:10:22.600 --> 00:10:25.199
as the first impression to LSP

00:10:25.200 --> 00:10:27.279
before even start writing code.

00:10:27.280 --> 00:10:27.280


00:10:27.280 --> 00:10:30.479
From a new user's perspective,

00:10:30.480 --> 00:10:32.959
they've just installed this package,

00:10:32.960 --> 00:10:35.159
and all they are expecting

00:10:35.160 --> 00:10:37.679
is using a smart autocomplete system,

00:10:37.680 --> 00:10:41.519
what does root directory even mean in this context?

00:10:41.520 --> 00:10:44.119
So we make the decision for them

00:10:44.120 --> 00:10:48.199
based on whether this file is part of a git repository.

00:10:48.200 --> 00:10:56.719
Often times we write code in its own standalone file,

00:10:56.720 --> 00:10:59.919
this is extremely common for scripting languages

00:10:59.920 --> 00:11:03.319
like bash or python. So in the single file model,

00:11:03.320 --> 00:11:07.159
LSP Bridge will start a dedicated LSP server

00:11:07.160 --> 00:11:10.319
for this particular file based on file type,

00:11:10.320 --> 00:11:13.479
and every file corresponds to a LSP server,

00:11:13.480 --> 00:11:17.839
so each server doesn't interfere with one another.

00:11:17.840 --> 00:11:23.719
The project model will have every file of the same type

00:11:23.720 --> 00:11:25.919
under the same project share one server.

00:11:25.920 --> 00:11:30.439
We believe this is a positive trade-off for user experience.

00:11:30.440 --> 00:11:30.440


00:11:30.440 --> 00:11:36.599
LSP Bridge internally implemented two main threads,

00:11:36.600 --> 00:11:40.399
one is the Request Thread, the other is Response Thread.

00:11:40.400 --> 00:11:45.279
The Request Thread is used to handle all the requests

00:11:45.280 --> 00:11:48.679
coming from Emacs, it does not answer immediately,

00:11:48.680 --> 00:11:52.839
this is important because Emacs doesn't need to wait

00:11:52.840 --> 00:11:54.679
for any response under any reason,

00:11:54.680 --> 00:11:58.159
even if the server is buggy or died out,

00:11:58.160 --> 00:12:01.159
it shouldn't matter to the performance of Emacs.

00:12:01.160 --> 00:12:04.039
The Response Thread is used to handle

00:12:04.040 --> 00:12:06.559
the response coming from LSP servers.

00:12:06.560 --> 00:12:11.239
After retrieving a response, regardless of the JSON size,

00:12:11.240 --> 00:12:14.439
it sends to its own thread for computation,

00:12:14.440 --> 00:12:17.079
such as candidate filtering and renaming.

00:12:17.080 --> 00:12:19.999
Once the computation is finished,

00:12:20.000 --> 00:12:23.639
it will determine if this information is expired,

00:12:23.640 --> 00:12:26.399
if not, then push it to Emacs.

00:12:26.400 --> 00:12:26.400


00:12:26.400 --> 00:12:31.559
From the Emacs side, when it receives the LSP information,

00:12:31.560 --> 00:12:34.639
it only needs to determine the course of action,

00:12:34.640 --> 00:12:39.159
either popup completion, jump to definition,

00:12:39.160 --> 00:12:44.799
renaming action, or show references and show documentions.

00:12:44.800 --> 00:12:49.119
You see, from a user, all LSP Bridge doing

00:12:49.120 --> 00:12:52.279
is these 5 things, the user doesn't need to care about

00:12:52.280 --> 00:12:54.559
anything else like the complicated

00:12:54.560 --> 00:12:56.479
Language Server Protocols.

00:12:56.480 --> 00:12:56.480


00:12:56.480 --> 00:13:02.439
Python side caches heavy data

00:13:02.440 --> 00:13:06.279
such as candidate documentation and diagnostics.

00:13:06.280 --> 00:13:11.079
We process as much server data as possible in Python,

00:13:11.080 --> 00:13:15.759
and only pass to Emacs as little data as possible

00:13:15.760 --> 00:13:18.159
so it doesn't clog the Emacs thread

00:13:18.160 --> 00:13:19.799
and triggers garbage collection.

00:13:19.800 --> 00:13:19.800


00:13:19.800 --> 00:13:24.319
This design is critical, because all Emacs needs to do

00:13:24.320 --> 00:13:27.039
is sending LSP requests to LSP Bridge,

00:13:27.040 --> 00:13:29.439
it doesn't wait for a response,

00:13:29.440 --> 00:13:32.999
it simply knows what to do *when* there is a response.

00:13:33.000 --> 00:13:37.159
So the user's input immediately displays on the buffer

00:13:37.160 --> 00:13:39.559
well within the 40 millisecond window,

00:13:39.560 --> 00:13:45.199
and in the mean time, the user can continue to type

00:13:45.200 --> 00:13:48.199
if he doesn't need the help from LSP right away,

00:13:48.200 --> 00:13:51.279
it fundamentally resolves the stuttering problem.

NOTE ACM - Asynchronous Completion Menu

00:13:51.280 --> 00:13:59.079
Now I want to talk about acm-mode,

00:13:59.080 --> 00:14:09.599
which stands for asynchronous completion menu,

00:14:09.600 --> 00:14:12.479
it is a completion framework

00:14:12.480 --> 00:14:15.039
that currently bundled with LSP Bridge

00:14:15.040 --> 00:14:17.279
designed to accomodate for

00:14:17.280 --> 00:14:20.399
the asynchronous nature of LSP servers.

00:14:20.400 --> 00:14:26.919
It is a replacement for the built-in capf,

00:14:26.920 --> 00:14:30.359
short for completion-at-point-functions,

00:14:30.360 --> 00:14:32.519
used in almost everywhere

00:14:32.520 --> 00:14:35.759
including company-mode and corfu-mode.

00:14:35.760 --> 00:14:40.839
Yes, we unfortunately reinvented a very fundamental wheel.

00:14:40.840 --> 00:14:44.279
No, it wasn't an easy decision.

00:14:44.280 --> 00:14:47.879
However we still believe it's worth it.

00:14:47.880 --> 00:14:53.359
LSP Bridge initially used company-mode,

00:14:53.360 --> 00:14:56.119
then moved on to corfu-mode for a while,

00:14:56.120 --> 00:14:58.999
but eventually Lazycat determined

00:14:59.000 --> 00:15:00.719
that it is much more painful to write

00:15:00.720 --> 00:15:05.679
a lot of workaround code to force LSP Bridge

00:15:05.680 --> 00:15:09.959
to handle capf nicely than to just fork Corfu,

00:15:09.960 --> 00:15:11.999
remove all the capf code,

00:15:12.000 --> 00:15:15.239
and write a new completion framework from the remainings.

00:15:15.240 --> 00:15:15.240


00:15:15.240 --> 00:15:20.719
Performance wise, capf requires Emacs to store

00:15:20.720 --> 00:15:23.119
the entire candidate list

00:15:23.120 --> 00:15:27.159
when looking up candidate annotations.

00:15:27.160 --> 00:15:30.639
It needs to search through the entire candidate list first,

00:15:30.640 --> 00:15:32.599
then use the candidate as a key

00:15:32.600 --> 00:15:34.799
to search for the actual information.

00:15:34.800 --> 00:15:38.919
This entire process will be repeated every time

00:15:38.920 --> 00:15:40.679
when drawing the completion menu.

00:15:40.680 --> 00:15:45.199
This is truly intensive computing task for Emacs to handle.

00:15:45.200 --> 00:15:50.519
On top of that, the existing capf frameworks assume

00:15:50.520 --> 00:15:54.279
the candidate list, which is retrieved from the LSP server,

00:15:54.280 --> 00:15:56.839
to be ready and finalized in place

00:15:56.840 --> 00:15:58.719
when the completion popup occurred.

00:15:58.720 --> 00:16:02.119
However given the design of LSP Bridge,

00:16:02.120 --> 00:16:05.919
Emacs will not sit there and wait for the server response,

00:16:05.920 --> 00:16:10.439
instead the Response Thread may feed Emacs data

00:16:10.440 --> 00:16:14.919
whenever it's ready. This makes capf almost impossible

00:16:14.920 --> 00:16:21.919
to form a finalized candidate list during popup.

00:16:21.920 --> 00:16:21.920


00:16:21.920 --> 00:16:26.079
The complete reasons regarding why capf is incompatible

00:16:26.080 --> 00:16:28.679
with the asynchronous nature of LSP servers

00:16:28.680 --> 00:16:32.479
are very complicated and deserves its own talk.

00:16:32.480 --> 00:16:37.079
Lazycat wrote an entire blog post detailing his reasonings,

00:16:37.080 --> 00:16:40.999
while Corfu's author Daniel Mendler a.k.a minad

00:16:41.000 --> 00:16:44.239
also done his own investigations and experiments,

00:16:44.240 --> 00:16:47.239
and reached a common conclusion.

00:16:47.240 --> 00:16:50.919
For anyone interested, I've pasted the links

00:16:50.920 --> 00:16:52.759
to the corresponding posts here.

00:16:52.760 --> 00:16:57.399
Therefore, keep in mind that LSP Bridge

00:16:57.400 --> 00:16:59.919
can only use acm-mode to work nicely,

00:16:59.920 --> 00:17:03.359
so please disable other completion frameworks

00:17:03.360 --> 00:17:07.159
like company and corfu before trying LSP Bridge.

NOTE LSP Bridge + ACM -> Multi-Backend Completion Framework

00:17:07.160 --> 00:17:14.919
By designing ACM with asynchronous server response in mind,

00:17:14.920 --> 00:17:18.759
this unlocks LSP Bridge project's potential

00:17:18.760 --> 00:17:22.199
to provide completions from almost any backends.

00:17:22.200 --> 00:17:25.679
ACM has blended all the backends together,

00:17:25.680 --> 00:17:28.799
and configured a priority to display

00:17:28.800 --> 00:17:32.839
important completion results like LSP before other backends.

00:17:32.840 --> 00:17:38.559
It can autocomplete LSP, TabNine, Elisp symbols, yasnippets,

00:17:38.560 --> 00:17:41.039
even English dictionaries and much more.

00:17:41.040 --> 00:17:43.959
As long as you have the backends installed,

00:17:43.960 --> 00:17:46.319
they all work out-of-the-box!

NOTE Today and future. Join us!

00:17:46.320 --> 00:17:55.239
Although LSP Bridge is a relatively new package

00:17:55.240 --> 00:18:00.039
with just over 7 months old, it is already a success!

00:18:00.040 --> 00:18:06.599
As of December of 2022, we have 67 contributors

00:18:06.600 --> 00:18:08.439
making more than 1000 commits,

00:18:08.440 --> 00:18:12.679
and we reached more than 600 stars on Github!

00:18:12.680 --> 00:18:16.359
LSP Bridge is easily extensible,

00:18:16.360 --> 00:18:18.879
developing a new language backend is very simple too,

00:18:18.880 --> 00:18:20.639
feel free to join us!

00:18:20.640 --> 00:18:25.599
LSP Bridge is another successful example

00:18:25.600 --> 00:18:29.919
of extending Emacs Lisp with Python, and just like EAF,

00:18:29.920 --> 00:18:33.639
it demonstrated the potential Emacs can achieve

00:18:33.640 --> 00:18:37.039
when we jump out of the Lisp-only world

00:18:37.040 --> 00:18:39.199
and embrace other ecosystems.

00:18:39.200 --> 00:18:43.479
Recently Lazycat created a package called blink-search

00:18:43.480 --> 00:18:45.679
that leveraged similar ideas

00:18:45.680 --> 00:18:48.919
but an asynchronous search framework,

00:18:48.920 --> 00:18:51.239
as well as a package called deno-bridge

00:18:51.240 --> 00:18:53.119
that extended Emacs Lisp

00:18:53.120 --> 00:18:56.439
with Deno JavaScript TypeScript runtimes.

00:18:56.440 --> 00:18:57.559
Please check it out,

00:18:57.560 --> 00:19:05.199
if consider joining the development too!

NOTE Thanks

00:19:05.200 --> 00:19:08.599
This is the entirety of my presentation, thanks for joining!

00:19:08.600 --> 00:19:11.319
Me and Lazycat will be available

00:19:11.320 --> 00:19:20.240
to answer questions on IRC and Etherpad.