Nikodemus Siivola nikodemus@random-state.net writes:
It should be possible for Emacs to inform swank of the appropriate truncation length based on (window-width sldb-window).
Even if there's already a SLDB window at the moment where this decision is made (I doubt it, but I'm not really sure), there is no guarantee that it's not resized latter. In fact, if a horizontal split happens, I would expect it to be resized by the user.
FWIW, I think that truncating long values for emacs doesn't make any sense when there's nothing interesting to see on the same line after a value (and it's not the case with SLDB and locals, where each local has its own line). Emacs is perfectly capable of truncating long lines (when `truncate-lines' is set in the buffer), and it doesn't prevent the user from scrolling, seeing or copying the entire value if he wishes.
And if we want several values on the same line be all visible, 75 characters per value is too much.
It makes sense to truncate some very long strings (those which could cause emacs slowdown, or big latency for remote debugging), but it's more like 65536 characters than 75, at the very minimum.
(Fortunately, it's possible to open a SLDB's presentation in the inspector, then toggle inspector verbosity with "v", and see a long string in its full length. It doesn't work for other objecs, such as non-character vectors, but I can live with it: the inspector's way of displaying vectors looks much more silly for strings than for other kinds).