CC: Tweaked

CC: Tweaked

57M Downloads

Improved pretty-printing within the REPL

SquidDev opened this issue ยท 5 comments

commented

The current pretty-printer within the REPL is a little naive: it tries to use textutils.serialise, and if that errors just uses tostring. While that's sufficient for basic things, it rather stinks when you're trying to dump an object with methods, or recursive table.

It might be worth writing a custom pretty-printer for the Lua REPL, which handles functions, recursive tables, and coroutines (most likely just by tostringing them).

A couple of neat things we could try out:

  • Colours Oh no, more mbs!
  • Some level of "layout awareness". So short tables (such as { 1, 2, 3 } are displayed on one line, rather than 5.
  • Length limits - if we've got a massive table or string, there's no point trying to print the whole thing, as it'll just take a long time and not fit on the screen! It would be nice if we could restrict how much we print in one go.
    That said, this is kinda complex to do well - mbs tries to be smart, and still leaves a lot to be desired. A naive implementation (only do the first 20 keys, 1000 characters, etc...) may be sufficient.
commented

I do like MBS, but I do not want it built in. As far as too many entries go, perhaps if we had a textutils.pagedPrint-type approach but with a cancel button or timeout.

Edit: CTRL+T would be the cancel button. We just adjust it to not exit REPL during output.

commented

@JasonTheKitten While I'm not proposing copying the entire mbs pretty-printer, I'm curious as to which bits you object to?

commented

Nothing really. I really like the alternate autosuggest highlighting. I don't exactly like how it's REPL adds out[x] in front of every line if I remember correctly - You could just have 1 line to indicate this is return values

Edit, mbs just feels crowded

The out[] is annoying, and I do not really need to know were functions were defined

commented

I am thinking for REPL with my pagedPrint idea, we would probably print as we go, instead of pre-serializing everything.

commented

don't mind me, for the sake of keeping track, #195 is relevant in this issue as well