Page 1 of 1
Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 1:03 pm
by maxterm
- Reset Time/Byte Counter:
It would be helpful to have an option to reset the time/byte counter without having to quit the application. Perhaps the arrow in the status bar, which currently changes the baud rate or disconnects, could be replaced with a button to reset the counter. Since there’s already a Connect/Disconnect option in the toolbar, I think it would be more intuitive to allow users to change the baud rate and parity by clicking on the baud/parity display. This approach, similar to the old ZTerm, is particularly useful when the required baud rate is unknown. More space between the time and byte counter would help as well, to make it easier to read, since time and bytes are both frequently updating.
- Dynamic Window Header:
A dynamic window header showing the current terminal size in rows and columns (e.g., "Untitled -- 80 x 40") would be beneficial, similar to what the Terminal app does under macOS.
- Platform Defaults:
The current defaults do not work well with macOS and likely not with Linux either, due to their use of the same line endings. Neither macOS nor Linux uses 0D (CR) for newlines, and they haven’t for some time—except for macOS Classic, which is no longer a concern. Command-line, console, or terminal-related tools, as well as standard text editors, do not interpret 0D (CR) as a newline. If CoolTerm interprets 0D (CR) as a newline, it can lead to unpredictable behavior. CR is still used for moving the cursor to the beginning of a line. For instance:
Code: Select all
$ printf "abcdefg\r1234\n"
1234efg
$
I achieved correct results by setting the Enter Key Emulation under Options to "LF" and enabling "Handle CR as Real Carriage Return" in Data Handling. I suggest making these settings the default for macOS and Linux users. For those who may not be aware, the current setup can create confusion and lead to incorrect display results, such as double prompts and empty lines.
Re: Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 3:12 pm
by maxterm
One more thing, I forgot to mention...
- Built-in TFTP server
How feasible would it be for CoolTerm to include a built-in TFTP server feature. X/Y/Zmodem protocols, while nice to have, aren't really contemporary file transfer options anymore. Nobody wants to wait 30 minutes to transfer a 16 MB firmware file at 115200 baud. NAS devices, pretty much all networked devices with a serial/debug ports have Ethernet and the boot loader typically supports TFTP.
MacOS and Linux ship with a built-in TFTP server, which can be enabled, and the process is not rocket science, but they operate under OS system access restrictions. If CoolTerm were to incorporate its own TFTP server, it could bypass these limitations, allowing users to specify directories without the typical world-access constraints inherited from parent directory structures. This would enable more convenient directory assignments, on demand, including temporary use for tasks like firmware downloads or backups.
Re: Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 3:41 pm
by roger
maxterm wrote: ↑Sun Sep 14, 2025 1:03 pm
- Reset Time/Byte Counter:
It would be helpful to have an option to reset the time/byte counter without having to quit the application. Perhaps the arrow in the status bar, which currently changes the baud rate or disconnects, could be replaced with a button to reset the counter. Since there’s already a Connect/Disconnect option in the toolbar, I think it would be more intuitive to allow users to change the baud rate and parity by clicking on the baud/parity display. This approach, similar to the old ZTerm, is particularly useful when the required baud rate is unknown. More space between the time and byte counter would help as well, to make it easier to read, since time and bytes are both frequently updating.
Thanks for the suggestion. I can add the option to reset the timer and counters to the context menu in the bottom left corner in an upcoming release. Meanwhile, it's possible to reset these counters by disconnecting and re-connecting, if so enabled in the "Miscellaneous" settings under "Status Bar Options".
- Dynamic Window Header:
A dynamic window header showing the current terminal size in rows and columns (e.g., "Untitled -- 80 x 40") would be beneficial, similar to what the Terminal app does under macOS.
Thanks. I'll see what I can do in a future release.
- Platform Defaults:
The current defaults do not work well with macOS and likely not with Linux either, due to their use of the same line endings. Neither macOS nor Linux uses 0D (CR) for newlines, and they haven’t for some time—except for macOS Classic, which is no longer a concern. Command-line, console, or terminal-related tools, as well as standard text editors, do not interpret 0D (CR) as a newline. If CoolTerm interprets 0D (CR) as a newline, it can lead to unpredictable behavior. CR is still used for moving the cursor to the beginning of a line. For instance:
Code: Select all
$ printf "abcdefg\r1234\n"
1234efg
$
I achieved correct results by setting the Enter Key Emulation under Options to "LF" and enabling "Handle CR as Real Carriage Return" in Data Handling. I suggest making these settings the default for macOS and Linux users. For those who may not be aware, the current setup can create confusion and lead to incorrect display results, such as double prompts and empty lines.
This one is a little trickier. The Enter Key emulation as well as the interpretation of line endings of received data is really a function of the device that CoolTerm is talking to on the other end of the serial connection, not the local platform CoolTerm is running on. So, using the host platforms defaults in CoolTerm might not be the best solution. So, I picked the most common one. The default in CoolTerm, regarding of the platform it's running on is CR+LF. This works for many of the things users might be communicating with, but not all, as you have found. I have come across weird cases including one where a device expected sent lines to be terminated with an @ character instead of a line ending. CoolTerm provides the necessary flexibility to deal with targets like that.
But it all you ever communicate with requires the enter key emulation to be set to LF and handling CR as a real carriage return, then you can make these your default settings by saving the current settings with these option set as default (File -> Save As Default). Any time you launch CoolTerm or open a new terminal, these settings are applied as default.
Also, pressing either SHIFT or ALT (or OPTION on macOS) together with ENTER or RETURN will override the Enter Key Emulation setting and type line endings as follows:
Code: Select all
Key Combination Line Ending
SHIFT+ENTER CR
ALT+ENTER LF
SHIFT+ALT+ENTER CR+LF
Re: Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 5:04 pm
by maxterm
I don't know any devices or operating system worth mentioning that expect CR to be interpreted as newline. Speaking of the 0D 0D 0A at the login prompt, as mentioned in another post, it does that for reasons to be compatible with DOS/MS-Windows, which traditionally relies on CRLF as newline for plain text.
Let's not confuse what is required to maintain file level compatibility between different platforms, because there simply is no compatibility. Unless you're dealing with application or rich text formats, speaking of clear text only, you will always need to convert files between MS-Windows and Unix-alike in order to maintain proper line endings. Consoles and terminal are not limited by the same restrictions.
Linux, MacOS and Unix use 0A (LF) for newline. These platforms don't use 0D (CR) to advance the cursor to the next line; only to the beginning of the current line. Hence, 0D 0D 0A will pretty much work on any platform and console worth mentioning. Under Linux and MacOS, the 2nd 0D is simply redundant; it just moves the cursor to the beginning of the line twice, which has no ill-effect.
Therefore I think no console or terminal should take an incoming 0D (CR) as newline. You can use CRLF for newline, but not CR. If CoolTerm interprets 0D 0D 0A as 2 newlines, it causes unpredictable results.
Re: Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 5:18 pm
by maxterm
So put simply, you can have the Enter key produce CRLF and it will work under MacOS/Linux and MS-Windows with no ill effects when the target is a console or terminal. But it causes unpredictable results if the terminal treats CR as newline.
Re: Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 5:38 pm
by maxterm
Btw, the Return and Enter key (numeric keypad), both issue CRLF (or LFCR on some ancient platforms). The reason why the Return key and Enter key are different on a hardware level, stems from the use of the numeric keypad as an application specific keypad, providing application or editing functions, often in combination with the NumLock key aka. Gold key. Unlike the regular Return key (US-ASCII), keys on the numeric keypad can be programmed to perform custom functions, similar to Functions keys, except F1 - F5, which were initially reserved to setup your CRT terminal.
Re: Coolterm suggestions/improvements
Posted: Sun Sep 14, 2025 7:24 pm
by maxterm
Correction: Both Return and Enter key primarily generate LF. The translation into CRLF happens at the OS/Keyboard driver level done by MS-Windows, which initially ran on MS-DOS in early days, relying on CRLF as newline.
MS-DOS, derived from CP/M, which used CRLF for newline. CP/M inherited it from the various DEC operating systems which influenced CP/M designer Gary Kildall. PDP and DEC-VMS, however, used LFCR, which is closer to how line printers actually work, doing LF to feed the paper and then CR to move the print head back to the beginning. This is obviously necessary, to prevent moving the head over printed text. So maybe CP/M got it wrong and confused LFCR for CRLF, and so did MS-DOS and MS-Windows?
Unix always used LF for newline with efficiency in mind, being compatible with CRT Monitors (VT-Terminal) and keyboards at the time. These monitors relied on CR to move the cursor to the beginning of the line, to overwrite previous text, and LF for newline. Unix converts LF to LFCR requirements on a driver level only where needed, like sending output to a line printer. Btw, commands like print, printf output text to the console, which can be a monitor or printer.
MacOS Classic used CR for newline, for reasons, who knows?