To archive this, the previous MIT-License and its mentions were removed, COPYING
was added, LICENSE.spdx and README were modified to show the correct
license, sils@sils.li was added to the project's
E-Mail adresses and ./scripts/renew_copyright_header.sh
was executed.
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.
Multiple things are still missing:
- [ ] Table type support
- [ ] Error messages and Status messages in ci input field (not in the status panel)
- [ ] Better ux in the ci input field (scrollback more than one line, syntax highlighting, &c)
- For further checkboxes take a look at the `FIXME`s and `TODO`s in the code.
The base ci although is already usable and in some way useful
The event handling is deeply ingrained in the ui code, the commands are
focused around the ui code, in short splitting of the event handling and
command system from the ui is intentionally hard and in my opinion not
really worth it right now.
Compiling the whole tui stack, just to debug the lua command line seems
counterproductive to me. This allows to just compile the needed parts
for a basic lua repl.
As of yet the repl is just a mock-up, as the event handling can, as of
right now, not easily be separated from the tui.
To activate specific features add specify the on the cargo command line
like this:
```
cargo run --features "cli tui"
```
or add them to the `default` feature set in the `Cargo.toml`.
Wildcard version is comparable to selecting a version depending on
the result of a dice roll. What I mean with this is, that the version
will be selected based on what the specific user already has in their
cargo registry. This means that the same codebase will compile
wonderfully on one machine but will fail with weird errors like:
`the trait 'From<crossterm::event::Event>' is not implemented for 'Input'`
on an other one.
Additionally crates.io does not accept crates with a bare wildcard
version requirement for aforementioned reasons.
Lastly using direct versions requirement allows to use `cargo upgrade`
to automatically update these requirements to their highest possible
value, as determined by SemVer. This works especially well, when adding
new dependencies with `cargo add`, as this also adds a direct version
requirement.
antifallobst
Silas Schöffel
Benedikt Peetz