The serial monitor very much needs a command history, ala bash or readline()
Hi @DrN. I'm not sure it is what you are requesting, but it does have something like this already. Click on the message field and then press the ↑ on your keyboard to fill the previously sent messages, with each press taking you to the previous item in the history. The ↓ key does what you would expect.
No, I mean for repeating previous command (i.e. message) to the Arduino.
Usually there is up/down arrow, and also a ctrl-R followed by the first few letters.
it is incredibly tedious to have to type the same command over and over again for testing.
Then use a terminal emulator like Putty, Tera Term, etc. It has that feature and a lot more useful stuff.
The terminal monitor in the IDE is convenient for recompiling and uploading. Again that is the use case for testing.
The terminal emulator has to be exited before uploading and started again for each recompile. Very nuisance-some
And I have my own monitor of course, python and multitasking, with a logging window. But is the same problem, it has to be exited before uploading, and flakes when the serial interface disappears.
The IDE is the place for supporting testing. That is a usual use case for an IDE.
Okay, good. I hope we agree that it is needed and hopefully, whoever owns development for the serial monitor will implement it. It is a pretty ubiquitous feature nowadays and especially for a testing environment it really should be there.
It is not intended for serious troubleshooting or testing. It is just a very feature limited educational device, and really doesn't pretend to be more than that. Most users never develop a sketch to the point where it has anything like a command line interface, so what is the point?
I think if you look around at other IDE's, you would likely find that none of them have this feature.
Also the feature is usually executed by the program that is running the command line interface. That is running on the Arduino, not the terminal. It is atypical for a terminal to have this feature. If you want to implement this feature in your sketches, you can.
You can store the last received command and create a "history".
I use the arrow up key (ESC sequence) to scroll back in list of previously received strings (commands). I store every last string received in my history.
It copies just from history to buffer where also UART would receive - I kick of my command handler with the "new" string received (even it was copied from history buffer, but behaves like a new string received).
Not difficult, just consuming a lot of memory (therefore it is not in as default, how deep? how to activate the history function? ...).
A terminal program (the host SW) can do as well. It depends which tool you use.
Terminal App with history
I'm just saying, normally this is not a terminal feature. I don't think it was ever part of the VT100 command set for example, and that's a respectable terminal.
Yes, I agree: it was never part of a specification for UART (is not related to).
I think, it was in UNIX systems, implemented on the system itself, see the "history" command on command line.
It is more a command line feature (independent of UART and terminal).
Still it's very much needed for this use case, development and testing.
100 lines would be good, 1,000 might be excessive.
Re unix systems, it is a standard part of the shell. in python there is a history capability built into the input() function.
I remember the VT100, I think I recall that DEC eventually provided the history capability in software. Was it DCL? It's been a while.
Anyway, we need it for this.
Who has mentioned DCL?
VT100 is a standard for characters via UART, esp. how to understand control characters (e.g. arrow up, arrow down, called ESC-sequences, codes starting with ESC (0x1B)). It does not define any "history".
A history function is a feature of the system, e.g. your MCU.
100 lines history: OK, but how long? each as 1024 bytes possible? So, 100KB just for the history?
OK, if you have so much available.
How to activate the history?
UNIX systems have a command for it like "history": it presents the list of recently stored received string. You can do the same.
You can also add "arrow up" and "arrow down" handlers, in order to scroll through the list.
Your, simple implementation:
you store just the very last string received. If user enters dot (a single ., at the beginning of line), you pull the last string, you display the last string and you let user to hit Enter to confirm (to take again as command).
Displaying the history, selecting an entry, firing this selected one ... is more a topic to create a "Display" and to navigate through a list. Is is more an UI issue instead of storing the last received strings. It can end up in heavy code, e.g. to display list, scroll through, select an entry ...
On small MCUs with small code and RAM space - why? Repeat the last: why not. And a simple dot (.) entered can repeat the last. But a full history list - memory space and code!
I wrote a terminal server, one day I will release it but it needs some fine tuning. It does a lot, but not that. If I wanted a history, I would create another software layer to do it, because it's not associated exclusively with a particular command interface. History really only makes sense with a command line interpreter, so if I were to add it to an application of mine that looks like this
red intensity set to: 17
command:r18
red intensity set to: 24
command:d
background colour set to: black
command:d
background colour set to: night blue
for example, I would like to either integrate it with the CLI code, or position it in a layer between the terminal server and CLI.
To illustrate a situation in which I would not welcome a history, a simple prompt like
What is your favourite colour?
can not utilize and should not implement history, because going back to the last response makes no sense. If it is in the terminal emulator, it ceases to be optional, and I don't welcome that.
You could use a flag (a "state machine") which would distinguish if it is a command to store in history or a subsequent question you ask (do not store it). Just have "states" to know if it is a "root command" or a "subsequent communication", in order to decide what goes into the history.
You are right: a host terminal tool would store all in history. But you can decide inside MCU FW what is a command and what not (based on a "state").
Yes. By the way I've often wished there could be some integration between the IDE and a terminal emulator, such that the upload is transparent. I guess the problem is that the terminal has to have the capability of being ordered to release the port. Given that the terminal knows nothing about other programs that use the port, that makes things pretty impossible. But it sure would be nice. Could it be done with a virtual, shared port maybe? That's over my pay grade.
To explicate a need, much software that I write has a command interface for either a "dumb terminal" or TTY, or else VT100. Thus both term em and Telnet/SSH. So the serial terminal in the IDE works, but doesn't allow me to do full testing. So really there isn't a choice for me when I'm working on those.
Sorry, I am lost...
Well I was going back to the original question a bit..
This one is about hardware ownership at an OS level being fixed, one client at a time. I'm saying, the IDE doesn't have to worry because it has full control and just makes it flexible, if the serial monitor is open when you upload, it just closes it IIRC. But the IDE can't and shouldn't close Putty or whatever, it should only pause it.
So I'm asking what if, a third party app opens virtual com ports for both the IDE and the terminal. Connects those to the actual serial port that is connected to the Arduino. Now if it detects an upload, passes it transparently to the port. Terminal remains unaware, or gets a small notification. Not possible?
That is essentially how it works. You must press the Enter to send the message once you load it from the history using the arrow keys, but I think that is a very sensible and intuitive requirement.
I don't know about Arduino IDE 1.x, but in Arduino IDE 2.x it is 100: