Every time a VS Code release uses a new version of node, every extension that uses node native integration breaks until it and all its dependencies are recompiled for the right version of node.

I hadn't thought of this

Their code is complex in ways the CLI makes unnecessary. As a result they are unable to be responsive to user suggestions and requests.

I believe the extension has been developing over time and handles a lot of cases because of the next point

It depends on the presence of the Arduino IDE (I think they're using it to compile)

Yes, they use kind of a "hidden" feature which is the internal arduino-builder. With the new CLI we're trying to replace its functionalities to make it a more modern tool which allows advanced users (and automation enthusiasts) to do more in a more structured (hopefully elegant) way. Of course we also have to maintain a lot of legacy behaviour which makes us sometimes introduce regressions people are not too happy about, that is why we still consider this tool an Alpha

There is absolutely no automation of paths for libraries. The vast majority of Arduino users are new to programming and are not ready to troubleshoot pathing problems for the VS Code C++ language support in order to get Intellisense code completion and edit-time static checking.

this is a rather tough one we are working on for the new IDE, and Language Servers have rather complex workflows. Because of how Arduino tends to simplify a user's life by automating, collecting, assembling, pre-compiling, some things are not easy to achieve, but we're convinced we're close to a solution that will allow correct library and source indexing for code assist

Serial monitor: if the ino file sets a speed for Serial then that is the speed the serial monitor should use. It's really not hard to look for Serial.begin(([0-9]+)) but they don't.

This is something we also don't do in our own IDE, and although I can see it could be useful it requires code scanning on a window basis, don't set your hopes high for this :D

If there is exactly one board detected then autoselect it. But they don't.

with this we go back to scanning serial ports on the machine for connected serial devices, which can be easy on windows but on Linux/Mac you'd have several devices only one of which might be a bootloader-ready board. Check out my arduino-cli board list output, for example, and consider I have no board attached

Port                            Type        Board Name FQBN Core
/dev/cu.Bluetooth-Incoming-Port Serial Port Unknown
/dev/cu.Bosone-SPPDev           Serial Port Unknown
/dev/cu.Bosone-SPPDev-1         Serial Port Unknown
/dev/cu.Bosone-SPPDev-2         Serial Port Unknown
/dev/cu.Bosone-SPPDev-3         Serial Port Unknown
/dev/cu.Bosone-SPPDev-4         Serial Port Unknown
/dev/cu.Bosone-SPPDev-5         Serial Port Unknown
/dev/cu.Bosone-SPPDev-6         Serial Port Unknown
/dev/cu.JBLFlip5-vCOMM          Serial Port Unknown

the CLI or an IDE have no way to know wether this is an Arduino compatible board.
The same is true for our IDE(s)

If you don't specify a satisfied path for arduino-cli then I can download and install it and likewise for cores and libs. They don't.

I don't think I get this point :)

Uh oh!

Detect programmers #968

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions