I came up with an algorithm and implemented it in Rust.
I want to ensure the code is of sufficient quality before releasing it on Crates.io and GitHub. You can also find more info about the algorithm and its purpose there.

I'm eager to hear your feedback and thoughts and am open to ANY suggestions that may help me improve the code further.
The code should be performant, clean, easy to use, idiomatic, etc.
I'm also looking for potentially better names for certain variables and stuff.

Note that some things have changed a bit since the last release (for example - the hash calculation has been changed from blake3(blake3(OBJECT) || blake3(DATE)) to blake3::keyed_hash(DATE, OBJECT) to improve performance by eliminating 2 out of 3 hash calculations), but the README is still valid (and hopefully at least somewhat decent source of info about the algorithm - I did my best trying to explain stuff, but I'm

Hello, I am new to this community, as well as to coding in general. I am having fun learning C, and I've generally been able to work through/slam my head into problems until they make sense, but I am confounded by this discrepancy, and I am hoping to have some help with it:

printf("%%c);

Output: %c

 undefined

    
#include 

void textGreen(const char* text)
{
    printf("\033[32m%s\033[0m", text);
}

int main()
{
    textGreen("%%c\n");
    return 0;
}


  

Output: %%c.

Since printf is wrapped into the function, should the text not be outputting with the same behavior? Why is my terminal printing this code without escaping the percent sign? FWIW, the text is green, at the very least.

I am using Ubuntu 23.10, the code was written in KATE, it was compiled in GCC, and it was run on the basic GNOME terminal.

I wrote a simple algorithm for predictive text that uses preceding words as context. Without looking at prior, it was an attempt as seeing what I could come up with.

The goal is for it to be incorporated in chorded input and pick the best candidate for the entered chord with the given context. Chorded input is the method of hitting all keys for a word simultaneously instead of hitting each key individually in expected order.

E.g you've typed "this is the worst" and hit the chord "aet", which word should be chosen? ate? tea? eta? This algorithm is there to answer that.

What I'm looking for in the code review in order of importance:

• documentation (is it understandable? are there things missing? ...)
• code architecture, code structure (function should be a member? composition could be changed? clarity, ...)
• algorithm review (optimisations, improvements)
• variable and class names (naming things is hard)
• rust specific stuff (f64 instead of u32 maybe? dyn vs impl? ...)

The c

I'm making an offline first, note taking application made with rust+tauri. I've reviewed this before with one of my friend and he checks everything from the way I use the library, how I uses my nonces, salt, and the like. But It's never a bad thing to ask you guys for some thought, if any.

Please take it slow, assume the best, and be gentle with me.

Source forges like Gitlab, Gitea, Forgjo, Github, and others do not allow directly leaving comments on code. However, they all do allow leaving comments on pull/merge requests and individual commits. This unfortunately doesn't work for snippets like Gitlab Snippets, Github Gists, etc. .

We can however use these to our advantage and use workarounds in order to make certain parts of our code reviewable:

Snippets

Create a repository to host your snippets (if you don't have one already), add your snippet of code as one commit to the repository (can be in a throwaway branch, the master branch, whatever). Share that commit link!

Larger changes

If you have code that belongs together, it is already in your repository, and is spread out over multiple commits, fear not! Once again, you can use the power of temporary branches. With these methods you can even have your entire repo reviewed.

A commit to review

Create a new branch, delete the parts of the code you want reviewed, creat