Autoscrolling with M105 and M27 hidden

[tjhowse]

If autoscroll is enabled, along with M105 and M27 hiding enabled, the terminal still scrolls to the bottom when an M105 ack message is received, even if it's not displayed.

[daftscience]

I can see how that's annoying, but the simple fix is to disable auto-scroll. What's more annoying is that the terminal will start scrolling when you run out of buffer (is that the right word?) regardless of how auto-scroll is set.

My rough idea... Filtering before it gets that far. The downside is that info will be lost for all eternity. Also, I can imagine it will break the resend requests and possibly temperatures?

Tom

P.S. as a bonus though, it could help keep errors in the terminal that otherwise would have been pushed out. Another idea I had was colorizing errors.

[foosel]

Nah, it won't break that (separate storage), but since the information
would be lost for all eternity as you said so nicely, I so far decided
against that. So right now the filtering is only done client-side, based on
the whole log provided by the server, and the "scroll to the bottom code"
right now does not discern between filtered and unfiltered lines. Should be
solvable quite easily. The buffer running out however is a different kind
of beast. I thought about increasing the buffer size, but I honestly don't
know whether the terminal tab is really THAT important (when you also can
enable the serial.log for debugging purposes) to risk higher memory
consumption.

[daftscience]

An increased, or variable, buffer size would be nice. But for the most part I think you're right, with logging enabled you can get all the comms, and with feedback control you can store any info.

A better way to put it would be to preserve important data, as opposed to filtering unimportant data (i.e. errors and EEPROM values.) Keeping resend requests, or errors in general will help track down problems that otherwise could be missed if logging was off. EEPROM values would be useful to where you send M503 and want to refer back to those values (I haven't gotten around to making a feedback command for all the values yet.)

[tjhowse]

Would a potential solution be to maintain an unfiltered buffer in parallel to the displayed buffer, and derive the latter from the former based on the filter settings? An alternative would be to maintain a larger buffer on the server and have the filtering done server-side. I'm not sure what architectural changes would need to take place for that to work however.

[foosel]

@tjhowse that's basically what's being done right now. The client maintains an unfiltered buffer, and creates the filtered output based on that. Filtering server-side would make the client-server-communication quite complicated -- right now the server just pushes data to the connected clients, not caring about who those clients are.

I'll take a look into the configurable amount of lines, that should hopefully mitigate the issue a bit (although increase client memory consumption), and for all the rest there's the serial.log.

[foosel]

For some reason I forgot to reference this issue when I reworked the terminal tab a couple of weeks back...

Disabling Autoscroll now completely disables cutting off the lines (so you can have way more than 300 lines while that's disabled), filtering has been improved too and doesn't cause scrolling anymore. See e9623fd.