Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoscrolling with M105 and M27 hidden #286

Closed
tjhowse opened this issue Oct 21, 2013 · 6 comments

Comments

Projects
None yet
3 participants
@tjhowse
Copy link

commented Oct 21, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2013

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

This comment has been minimized.

Copy link
Owner

commented Oct 21, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2013

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

This comment has been minimized.

Copy link
Author

commented Oct 22, 2013

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

This comment has been minimized.

Copy link
Owner

commented Oct 27, 2013

@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

This comment has been minimized.

Copy link
Owner

commented May 5, 2015

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.

image

@foosel foosel closed this May 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.