[slime-devel] slime debugger string length cutoff, bad default and how to control it

[Anton Kovalenko]

Nikodemus Siivola <nikodemus at 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).

-- 
Regards, Anton Kovalenko <http://github.com/akovalenko/sbcl-win32-threads/wiki>
+7(916)345-34-02 | Elektrostal' MO, Russia