This obviously is a big regression, but having this matrix code in the
core trinitrix tree is no longer planned. And if we start writing the
matrix cbs, referring to this commit should be possible.
Parsing right now works by simply comparing the input string:
```
"/" -> <comment_tokenizer> -> "/" -> <normal_comment>
|-> "//" -> <doc_comment>
```
A better method to do this though would be to turn "//" and "///" into
keywords and simply leave the parsing to the parser module not the
tokenizer.
By now a wrapped version of mold exists, which thus works with the
NixOS libraries. This is obviously the same as my self-wrapped version,
but vendoring is just not important here.
Motivation
==========
The self-packed one sort-of worked, but was rather flaky, while the one
from rustup obviously works, as it's an officially distributed part.
Running it
==========
Instead of the `cargo clif [build, etc.]` you now need to run (on nightly):
```
RUSTFLAGS="-Zcodegen-backend=cranelift" cargo build
```
Performance
===========
On my system I noticed, that a debug build takes around 20 sec *more*
with cranelift, compared to the default LLVM backend.
One possible hypothesis, for that could be, that cranelift does
not link via `mold` but instead still uses GNU's `gold`.
On the other hand, the performance decrease could also be caused
by the fact, that it's an early preview and some optimizations are
still lacking.
This commit fixes multiple bugs introduced in the new keymapping system:
When we can't find a keymapping for a string, we simply pass it
along, by calling the 'send_input_unprocessed' function with the
inputted key turned into it's string representation. Turning a shifted
key into it's repr. returned a doubly shifted string:
'A' turned into '<S-A>', which then fails to parse as a valid key
input. Thus, we simply unshifted the value.
The next bug, becoming apparent now, is caused by this: We never
reshifted the value, when we converted it into a crossterm key input
event.
Benedikt Peetz
antifallobst