I thought this
(setf (cdr (assoc 'swank::*sldb-string-length* swank:*sldb-printer-bindings*)) 5000)
would do the to show my all of a 100-long string in SLDB.
(I think the cutoff should be much higher by default, by the way.)
But when I looked at locals in SLDB, I had a string of length 100 shown with its first 74 characters, followed by two dots (..). (Uh, not to pile on, but wouldn't three dots (...) be normal?)
When I evaluated swank::*sldb-string-length* (typed 'e', swank::*sldb-string-length* to the Eval in frame: prompt below), the value was nil.
What is going on?
My test was
(defun foo () (let ((x (make-string 100 :initial-element #\q))) (break "foo") x))
(foo)
The debugger showed me
foo [Condition of type SIMPLE-CONDITION]
Restarts: 0: [CONTINUE] Return from BREAK. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [*ABORT] Return to SLIME's top level. 3: [ABORT-BREAK] Reset this thread 4: [ABORT] Kill this thread
Backtrace: 0: (FOO) Locals: X = "qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq..
* Mark H. David [2011-11-27 14:11] writes:
I thought this
(setf (cdr (assoc 'swank::*sldb-string-length* swank:*sldb-printer-bindings*)) 5000)
would do the to show my all of a 100-long string in SLDB.
I removed swank:*sldb-printer-bindings* a few days ago as it little effect since a long time.
(I think the cutoff should be much higher by default, by the way.)
But when I looked at locals in SLDB, I had a string of length 100 shown with its first 74 characters, followed by two dots (..). (Uh, not to pile on, but wouldn't three dots (...) be normal?)
The "line" of for a local variable is truncated to 75 chars. That's what the two dots are saying.
Helmut
OK, how about a way to control the cutoff, or make the cutoff much higher? I'm the Lisp debugger, it's not prettier with 75 characters, just hiding my info.
----- Original message ----- From: "Helmut Eller" heller@common-lisp.net To: slime-devel@common-lisp.net Date: Sun, 27 Nov 2011 18:49:40 +0100 Subject: Re: [slime-devel] slime debugger string length cutoff, bad default and how to control it
* Mark H. David [2011-11-27 14:11] writes:
I thought this
(setf (cdr (assoc 'swank::*sldb-string-length* swank:*sldb-printer-bindings*)) 5000)
would do the to show my all of a 100-long string in SLDB.
I removed swank:*sldb-printer-bindings* a few days ago as it little effect since a long time.
(I think the cutoff should be much higher by default, by the way.)
But when I looked at locals in SLDB, I had a string of length 100 shown with its first 74 characters, followed by two dots (..). (Uh, not to pile on, but wouldn't three dots (...) be normal?)
The "line" of for a local variable is truncated to 75 chars. That's what the two dots are saying.
Helmut
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
* Mark H. David [2011-11-28 00:31] writes:
OK, how about a way to control the cutoff, or make the cutoff much higher? I'm the Lisp debugger, it's not prettier with 75 characters, just hiding my info.
It is prettier when each local variable fits on a single line. If we assume 80 chars per line and subtract some space for the variable name then no more than 75 are visible. For the full information you can use the inspector or the d command.
Helmut
Makes no sense to hard code this. You cannot predict terminal width -- I've got 256+ characters showing quite legibly on my screen -- nor width of the buffer being used currently in emacs. Nor can you predict the variable name.
----- Original message ----- From: "Helmut Eller" heller@common-lisp.net To: slime-devel@common-lisp.net Date: Mon, 28 Nov 2011 08:44:29 +0100 Subject: Re: [slime-devel] slime debugger string length cutoff, bad default and how to control it
* Mark H. David [2011-11-28 00:31] writes:
OK, how about a way to control the cutoff, or make the cutoff much higher? I'm the Lisp debugger, it's not prettier with 75 characters, just hiding my info.
It is prettier when each local variable fits on a single line. If we assume 80 chars per line and subtract some space for the variable name then no more than 75 are visible. For the full information you can use the inspector or the d command.
Helmut
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
* Mark H. David [2011-11-28 14:52] writes:
Makes no sense to hard code this. You cannot predict terminal width -- I've got 256+ characters showing quite legibly on my screen -- nor width of the buffer being used currently in emacs. Nor can you predict the variable name.
I can predict my terminal width high accuracy.
Helmut
I can predict my terminal width high accuracy.
*your* terminal width.
there are quite a few people to whom the 80 column rule doesn't make much sense anymore, and especially so when it's not about program code.
this was also annoying me since it was introduced, and i also tried to fix it using *sldb-printer-bindings* back then, but quietly gave up...
and while we are at it, the inspector displays strings as a vector of characters.
I can predict my terminal width high accuracy.
*your* terminal width.
And your terminal width is better than mine, right?
it's pretty obvious, but... what i meant is that the ability to predict *your* terminal width with high accuracy is a very weak argument for inflicting an arbitrary limit derived from that on the entire slime user base (modulo the forks with all their wasted divergence).
i wouldn't have pointed this out if you didn't try to defend the status quo on top of that, but rather e.g. shrug, and say that it's good enough for you as it is, and patches are welcome.
oh, but wait! are patches welcome?
Hmm, Gentlemen, please. There must be some past history bubbling up here?
I believe Nikodemus' solution is simple and could work, but doesn't handle resizing. Can't we just let emacs do the truncating?
On Mon, Nov 28, 2011 at 11:43 AM, Helmut Eller heller@common-lisp.netwrote:
- Attila Lendvai [2011-11-28 16:40] writes:
oh, but wait! are patches welcome?
Not yours.
Helmut
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
On 28 November 2011 17:07, Helmut Eller heller@common-lisp.net wrote:
It should be possible for Emacs to inform swank of the appropriate truncation length based on (window-width sldb-window).
Cheers,
-- Nikodemus
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).
On 28 November 2011 17:44, Nikodemus Siivola nikodemus@random-state.net wrote:
It should be possible for Emacs to inform swank of the appropriate truncation length based on (window-width sldb-window).
Attached a proof of concept patch for the debugger frame locals for this.
Widening or narrowing the window doesn't automatically change the length of the string, but hitting enter twice on the frame (hiding and reshowing it) takes care of that.
Cheers,
-- nikodemus
* Nikodemus Siivola [2011-11-29 08:45] writes:
On 28 November 2011 17:44, Nikodemus Siivola nikodemus@random-state.net wrote:
It should be possible for Emacs to inform swank of the appropriate truncation length based on (window-width sldb-window).
Attached a proof of concept patch for the debugger frame locals for this.
Widening or narrowing the window doesn't automatically change the length of the string, but hitting enter twice on the frame (hiding and reshowing it) takes care of that.
I've come to the conclusion that the only thing that "makes sense" to some people are customization variables. So let's see if they finally shut up if they get them.
Helmut
In article m28vn0wv1e.fsf@common-lisp.net, Helmut Eller heller@common-lisp.net wrote:
- Mark H. David [2011-11-28 00:31] writes:
OK, how about a way to control the cutoff, or make the cutoff much higher? I'm the Lisp debugger, it's not prettier with 75 characters, just hiding my info.
It is prettier when each local variable fits on a single line. If we assume 80 chars per line and subtract some space for the variable name then no more than 75 are visible. For the full information you can use the inspector or the d command.
Helmut
These explicit commands work on a single datum at a time, though. Sometimes you want to look at more items at the same time in more detail. What about a key (e.g. +) to reprint the items with an increased maximum length? You can press the key multiple times for increasing the detail level as desired. The same key can also apply to the inspector buffer.
T
-
Anton Kovalenko -
Attila Lendvai -
Helmut Eller -
Mark H. David -
Nikodemus Siivola -
Tobias C Rittweiler -
William Halliburton