Closed bjoernQ closed 8 months ago
As we also spoke on the past, if there was a way to introduce snippets in cargo-generate
, it would be even more helpful since it could also be used for non-VSCode users. And we could also verify the code on them, but, again, increasing complexity.
I think having simple projects with some pointer to esp-hal examples/project on the no_std training its also a very good solution, but if that is not enough, we can use these snippets and even add a step-by-step guide on how to add X support on the template readme.
As suggested by @jessebraham in the last community meeting, adding more and more options will make the template (even) harder to maintain and we probably should only generate a minimal project
As @MabezDev mentioned the thing users are struggling the most with is choosing the needed dependencies (and features) - so we probably should generate
Cargo.toml
even for more advanced configurations (embassy, wifi, ble etc.)One thing that came to my mind is we could still support at least VSCode users by providing snippets (see https://code.visualstudio.com/docs/editor/userdefinedsnippets) - and even add more convenience
e.g. adding ./.vscode/rust.code-snippets like this
Would give the user an easy way to create an SPI instance. Since snippets are not very powerful, they still need to figure out the right imports - we could just add a local
use
statement or (like in this very simple example) a commented outuse
statement which users can manually copy (or remove). Or don't do that and let the user use the quick-fix feature.We could also have snippets to add dependencies to
Cargo.toml
instead of generating it (e.g. a snippet to add embassy or esp-wifi)This way we could also add more elaborate snippets like setting up wifi, ble etc.
But I'm not sure if this is really a very useful thing or just sounds good in my head. I'm also not sure which snippets to include (for me I always have to look up how to setup some peripherals but maybe that's just me)
Downsides of this