The intention of this post is to get direct user-feedback.
The Arduino-IDE 2.X is out now for several months.
There is this issue with the serial monitor that the information that is printed to the serial monitor can't be copied into the clipboard.
So I decided to start a poll to get information about how important is solving this issue to the user-community.
For newcomers that only know the new IDE 2.2.1:
debugging with the help of the serial monitor
WAS
very useful in the old version. It was very easy to mark, copy 10, 20 or even hundreds of lines in the serial monitor.
In the new version IDE 2.2.1 you can only mark a few lines which is really crappy compared to version 1.8.19
A third option might be in order:
3) still waiting at 1.x for features (like this) to be ironed out, so neither poll option really applies to me.
By the way, can you at least ctrl-A, ctrl-C the Serial Monitor content in 2.x to get it all, reliably? (I don't intend to load it just to test it - bad me!) That might suffice in some cases, though deleting the unwanted lines could surely be painful.
I use SM on every project. Even in Wokwi, it's indispensable. Granted, I don't always, or even frequently, want to grab small snippets of output, but it happens. So, we'll wait. The likely downside of late transition is, I'll likely find some other feature(s) I could have complained about earlier. The plus side is, I may never need to transition; I'm already tinkering with compiling outside the IDE, and CLI is another option of interest (both along with third party terminal apps, of course), so... we'll see. I may well be gone, in one way or another, before it becomes necessary to leave 1.x.
Thanks.
The design of your poll is better than that of @StefanL38 (which is setting the lowest bar imaginable), but I feel it presents a false dichotomy. Where is the option for those of us who would vote "I'm willing to wait for a solution that doesn't significantly impact performance"?
There is no indication that it is impossible to provide the necessary copying capability without sacrificing performance. We don't know either way because nobody has done the comprehensive investigation that would be required to come to a conclusion either way.
Well I would add "We should continue to hold our breath for the Arduino folks", but it won't let me modify the poll.
Do you really think anyone at Arduino is concerned? There are new boards to push out before they're ready. Profits are the most important thing. Not user experience. I think that much has been well established over the last few years. This is not the same Arduino we used to have.
This is a real question:
In which way does an opened serial monitor impact performance of what?
It might be impossible to explain the whay in a few sentences but you should be able to at least name these things.
.
.
Like in IDE 1.8.19 It should be very easy to stop the serial monitor while compiling is active.
And what the heck for what do you need high performance once the compiling is done?
Does clang and all the other bells and whistles need so much performance?
How about having an option with something like
"high CPU-priority to either serial monitor or IDE "?
While running a code for debugging you need to watch the serial monitor
not looking up ressources. Not at the exact same time.
I am lightyears away from beeing a high experienced multithreading software-developper.
I have some autohotkey scripts running and to keep their CPU-load low I simply inserted a sleep(100) and it is done.
Sure receiving serial data requires more than making a autohotley-script sleep.
Still with a baudrate of 115200 it should be possible to keep the cpu-load very low.
The way I understand things we currently have a choice between being able to copy all of the serial monitor but also losing some data at high speeds or having a serial monitor that faithfully captures all the data but is hard to copy from.
It's not just being ignored and it's not just a simple fix like you seem to think.
So basically to support an overclocked Teensy 4.0 so a few people can generate text faster than anyone can read, no one can copy the SM output. What a very weird priority order.
So I guess we all have to fork the IDE the same way Paul did, in order to get a basic feature. If we do that, will it then become "a goal set for the Arduino developers when creating Arduino IDE was to provide the capabilities missing from Arduino IDE 2.x that forced people to create a modified version of the IDE"?
I like the way you put that. And the commonly suggested solution is to use a python code to write directly to a file or to use an alternative program for serial.
But shouldn't that be the solution given for those who want to do the extreme things? Should we really send every newbie who wants his serial output to python so a small community of high speed folks don't have to?
I wasn't voting before, but I think I'm convinced on voting with @StefanL38 on this one now.
As long as 1.8 is around and works with the boards I use ... why switch? Naturally a newcomer would be upset by that advice, but IDE2 is a resource hog - aside the fact it does not run on ARM (chromebook, RPi, ...) and 1.8 is included in devuan/debian repositories.
Sorry, it is probably just me, but I don't understand the purpose of this thread.
That is, I personally believe that the Arduino developers are aware of these issues.
There have been many threads on this already and several still active issues up on github... I know some of them are mine!
What has the Teensy 4 have to do with this? I know that even with the Teensy 3.x which is USBFS (12Mbs), the unmodified Serial monitor had issues, which is one reason PJRC had Teensyduino installs that would put in a modified version... And then yes T4.x comes along that is USBHS (480Mbs) i.e. up to 16 times faster on USB transfers. So yes, maybe T4.x was the first, or at least one of the first that can run at this speed, but I am guessing that now is not the only Arduino boards that can run at HS speed. And who knows maybe there are some that can output even faster, like maybe at USB 3 speed.
Note: The ability to capture data fast and the ability to be able to allow the data to be copied to the clipboard are not mutually exclusive. As already mentioned there are apps that do this today:
a) Arduino 1.x with Teensyduinos changes for Teensy ports.
b) TyCommander - Again setup for Teensy but also works on generic Serial ports.
c)...
So this really boils down to, it is a bug or bugs (or design issues) in the current code base.
The real question is, do you believe that this is the highest priority thing tha Arduino should devote their limited resources to, to fix these issues?
My guess if you asked 10 people what you believe their top priority should be, you would likely end up with 20+ answers.