CR+LF if idle for x milliseconds

if X was quite a big number it might work. I suspect that modern serial ports (usb) with big buffers & traffic reduction algorithms, usb framing, driver blocks etc etc etc, the data doesn't arrive at RT with timing aven vaguely resembling what it is on the wire.

What sort of data do you think this is useful for?
How does the receiving system normally frame it?

Any reply to question above?

What delay is useful for this feature?
(i.e. 1ms is going to be unworkable, 1sec workable, 100ms maybe)

Not sure how to fit it into the UI, but I am thinking it an extra timestamp checkbox,

It seems to me that it is more generally useful to other people as part of timestamping.

Perhaps a right-click hidden selector for the timeout period like the timestamp checkbox has

What DisplayAs mode are you normally using?

V3.0.0.32, added checkbox for "idle" and hidden timeout selector

Added "idle" checkbox

I'd love to add more than one upvote :-) This is exactly what I've been missing in RealTerm. Years ago I've written a simple piece of software for Linux (serial line hex-dumper with Curses output) that does exactly that same thing, but I don't have the time to port that to Windows and for various reasons I have to live in Windows most of the time. In Linux I could often detect timeouts as short as 10 ms.

When debugging various serial-based communication protocols and fieldbusses, most of them request-response based, the delays between two consecutive requests or responses are often plenty long enough for a PC with a bloated OS to detect a timeout. Certainly if the slave is not available, so that the master has to time out before trying the next node. Or if you have multiple slave nodes, maybe there's a chance to eavesdrop on one particular slave's TX only, which only gets the relay token once every so often. Some protocols just ask once every some time quantum and don't try to squeeze maximum time out of the serial link. The chances to utilize a timeout for frame separation is actually pretty good, in my daily practice.

If memory serves, in terms of WinAPI all you need to do is SetCommTimeouts(handle, ...) to some desired value and the subsequent call to ReadFile(handle, ...) will inherently apply the timeout, likely with support from the kernel. All you need to do is catch the "timeout" errors from ReadFile() and add a visual newline when a timeout occurs (for the first time after some data has been read).

I'm currently at RealTerm 2.0.0.70, and I haven't noticed any public "nightly" or "testing" builds... I'd like to volunteer as a beta-tester :-)

BTW, is there a chance to add a "manual" line break in the displayed data? When debugging some serial comms, often the communication is "on demand", and it would help me to separate subsequent "instances" of activity visually on the screen. AFAIU, in 2.0.0.70, I have no option to just hit enter a couple times (with the newline getting "locally echoed"). Not in a hex display mode.