You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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 out use 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
we cannot verify the snippets in CI
needs some maintenance whenever there are breaking API changes
might clutter the CTRL+SPACE code completion if we have a lot of these snippets
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: