It's not really about the editor. The editor (the LSP client) just provides support for telling the server what the user wants a definition for, and how to display that back to the user.
As a simple example, I'm learning japanese so I built a 50-line LSP server that just looks up definitions of a word under cursor in a dictionary. This is an almost-trivial server. Its only capability is to offer definitions when hovering a position in a text document. It works perfectly well in neovim with lspconfig with 2 lines of configuration. I'm sure it would be similarly trivial to integrate in VSCode, Emacs, etc.
Other non-coding uses of LSP that I'm aware of are spell-checking and grammar suggestions (LSP clients can display diagnostics), semantic syntax highlighting (e.g. for highlighting a markdown document), and projects like the one discussed here which just integrate more general-purpose AI.
You really don't have to understand any deep wizardry to get started (or, for the most part, even to finish). For the most part, you just look at a specification, and implement what it says. It requires some code architecting skill to not make a mess, but there are common patterns and it becomes a lot easier once you've built one or two emulators.
And you almost never need to understand electronics. You're only emulating behavior. When someone discovered bugs in the behavior of the original hardware, you usually just need to special-case it in your emulator. It might help to know some electronics to understand how those behaviors came to be, but that's more so of historical interest than actually practical.
There are certain unique challenges, but it's nothing too difficult. When there's an issue, you're usually debugging three things at once: Your understanding of the hardware, your implementation of the emulator, and the game you're emulating. It can be hard to pin down the exact problem. But here, I encourage you to just hack something together. It's not clean, but all emulators are full of special cases that try to somehow get popular games working. If a couple unclean hacks mean you can get a game working, just do so. You don't really need to exactly implement the original hardware's behavior. Just get the game working.
libc doesn't really have a concept of containers or iterators. The only container it knows is an array.
The one well-known "generic" algorithm in libc is qsort. But qsort only works with pointers, and so can only sort continuous containers. You can't sort a linked list with qsort. In contrast, the STL has a more general concept of iterators that know how to fetch their next element (and some iterators can do more than just that). This allows the STL to have a std::sort algorithm that works on arrays, linked lists, trees, and whatever other data structure you want to come up with.
So the crucial idea is that the STL provides a large set of algorithms that work on all containers. No matter what kind of weird container you have, as long as you can provide an iterator for it, you can use most of the ~100 different standard algorithms on it. You can sort, find specific elements, partition, find the max element, filter elements, etc.
And the idea also goes the other way around. The STL also provides common containers that you'll need, such as linked lists, growable arrays, associative containers, strings. Of course, all the STL algorithms work with the STL containers.
Then, if you want to write your own algorithm, you only need to write it once in terms of iterators and then you can use it with all the different containers. No need to write the same routine twice.
The last big accomplishment is that all this can be done with almost no runtime overhead. All the types are resolved at compile-time, and generic algorithms can be specialized if you have a more efficient implementation for a specific container. This means that if you wrote a manual implementation of an algorithm that specifically matches one container, it would not be much faster or consume fewer resources than just using the generic STL algorithm. At the time the STL was originally incorporated, I think this was unique and no other language was actually capable of doing this.
Serenity still has Ladybird as it is right now. So I assume that will become the baseline for "Browser" in SerenityOS going forward, and be developed independently. Whatever the browser in SerenityOS will end up looking like though, I doubt it will see much development. The kinds of people interested in working on browsers will just work on Ladybird.
Someone will probably once again port Ladybird to SerenityOS in the future. It won't be part of the main system, but users would be free to install it.
It's useful to consider the next answer a model will give as being driven largely by three factors: its training data, the fine-tuning and human feedback it got during training (RLHF), and the context (all the previous tokens in the conversation).
The three paragraphs roughly do this:
- The first paragrath tells the model that it's good at answering. Basically telling it to roleplay as someone competent. Such prompts seem to increase the quality of the answers. It's the same idea why others say "act as if youre <some specific domain expert>". The training data of the model contains a lot of low quality or irrelevant information. This is "reminding" the model that it was trained by human feedback to prefer drawing from high quality data.
- The second paragraph tries to influence the structure of the output. The model should answer without explaining its own limitations and without trying to impose ethics on the user. Stick to the facts, basically. Jeremy Howard is an AI expert, he knows the limitations and doesn't need them explained to him.
- The third paragrah is a bit more technical. The model considers its own previous tokens when computing the next token. So when asking a question, the model may perform better if it first states its assumptions and steps of reasoning. Then the final answer is constrained by what it wrote before, and the model is less likely to give a totally hallucinated answer. And the model "does computation" when generating each token. So a longer answer gives the model more chances to compute. So a longer answer has more energy put into it, basically. I don't think there's any formal reason why this would lead to better answers rather than just more specialized answers, but anecdotally it seems to improve quality.
It's a bit silly to abandon all contact with the world just because you have to wait for the doctor, go grocery shopping, sit in the train, etc.