-
Notifications
You must be signed in to change notification settings - Fork 139
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
"[sly-elided string of length 11]" is annoying as heck #334
Comments
Is there any way to disable string elision even for very long strings as a user preference? |
Don't remember anymore :-(, have to check the code. |
If you can do that for me, I'm fine. It's all Common Lisp anyway. |
Fixed. See the variable (setf (cdr (assoc 'slynk:*string-elision-length* slynk:*slynk-pprint-bindings*)) nil) in your |
+1 Super-annoying. (This should be opt-in.) |
As far as I no understand, the new variable controlling this is set to 100 by default, which means you really don't get many elided strings that would have been entirely visible anyway unless you use very small fonts |
FYI, I hit the problem with literate programming, in this case: SLY elided the output but not SLIME. P.S. I do not want the Org file to depend on |
Rudolf Adamkovič ***@***.***> writes:
As far as I no understand, the new variable controlling this is set to 100 by default, which means you really don't
get many elided strings that would have been entirely visible anyway unless you use very small fonts
FYI, I hit the problem with literate programming, in this case:
queens
SLY elided the output but not SLIME.
P.S. I do not want the Org file to depend on ~/.slynkrc configuration.
I don't know exactly what you're showing me. The screenshot looks fine.
Is it from SLIME? I know that an Org interface to SLY exists, but it's
not a part of SLY and I didn't write that code.
So if you're bumping into problems there, I would look into that code.
I can help you debug it if you give me a simple, easy to follow
reproduction recipe with NO extra packages other than Emacs (where Org
lives) and SLY. And a small .org file that I can open and do whatever
literate programming enthusiasts do there.
I hesitate to blame a feature that's designed for SLY's UI purposes and
not designed for interoperation with other packages. SLY should have
better mechanisms for that.
João
|
Thank you for the reply, and I apologize for not being clear.
Yes, from SLIME. (SLY elided the output.) I just wanted to show you a simple, real-world example where one stumbles upon this feature/bug.
Org works great with both SLIME and SLY, and SLIME works great out of the box when doing literate programming. However, SLY does not (by default), hence my original comment "This should be opt-in." |
What I'm trying to explain is that it's not that the "elided" feature fault. It's the fault of that Org code, which is misusing SLY's interfaces. It's using something meant to display information in the SLY UI to do literate programming things. I didn't write that Org code, someone else did. If you give me a way to test this, I can probably fix the Org code. It makes no sense to turn off by default an useful feature to appease some malfunctioning third party code. |
yup. ob-lisp.el is mixing up string return values and stream output. Arguably, even for SLIME it is wrong. If you want to output a large amount of data, you should use
This will elide the string indeed
But this is wrong anyway, because in good Lisp REPL tradition, it should return the string braced with quotes, so it is
I recommend you use Anyway, if |
If you can, please let us know what exactly can be improved in ob-lisp.el. That file currently has no maintainer, unfortunately. So, we have to rely upon user patches from people more familiar with Common Lisp and SLY. |
Since I implemented this, these cases keep popping up. This is meant for very long strings, not for such short strings. Have to investigate.
The text was updated successfully, but these errors were encountered: