Gobbel2000
I knew that shell files, especially in build systems can get hard to read, but this was absolutely painful to look at from start to finish, even with the very helpful explanations in between. Of course the obfuscation is mostly done by design in this case.
I don’t think there is a good way of having references within the same struct, but you could store reference counted matches:
matches: Vec<Rc<Match>>,
players: HashMap<String, Rc<Match>>,
You would still have to make sure that the players map is updated, maybe weak references are useful there.
Maybe you could also consider storing the players of a match in the match itself, not outside.
If there won’t be too many different plugins, maybe having a feature for each plugin would work. Then you could use --features=... when compiling to select the plugins you need.
While reading the question I thought: “That’s not how Watts work”, but then this “answer” hit…
I like to look at Issues and Pull Requests on Github if a crate wasn’t updated for multiple years. If there are already problems like unsoundness, deprecation, or breaking bugs mentioned with no reaction shown by the maintainer, that is a good sign to look elsewhere instead. If everything seems fine and the crate isn’t very complex or security-critical, it is probably not an issue.
Like someone noted in the vimtex issue you linked, I use UltiSnips together with snippet definitions from vim-snippets, which works pretty well with the begin snippet. vim-snippets includes a bunch more snippets too which I find quite useful, particularly for LaTeX. I don’t know the vsnip plugins you mentioned but they can probably do the same.
