"[sly-elided string of length 11]" is annoying as heck

[joaotavora]

Since I implemented this, these cases keep popping up. This is meant for very long strings, not for such short strings. Have to investigate.

[gefjon]

Is there any way to disable string elision even for very long strings as a user preference?

[joaotavora]

Don't remember anymore :-(, have to check the code.

[joaotavora]

If you can do that for me, I'm fine. It's all Common Lisp anyway.

[joaotavora]

Fixed. See the variable SLYNK:*STRING-ELISION-LEGNTH* and how it's used to control this. You should be able to

(setf (cdr (assoc 'slynk:*string-elision-length* slynk:*slynk-pprint-bindings*)) nil)

in your ~/.slynkrc to completely turn off string elision

[rudolf-adamkovic]

+1 Super-annoying.

(This should be opt-in.)

[joaotavora]

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

[rudolf-adamkovic]

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 ~/.slynkrc configuration.

[joaotavora]

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

[rudolf-adamkovic]

@joaotavora

Thank you for the reply, and I apologize for not being clear.

I don't know exactly what you're showing me. The screenshot looks fine. Is it from SLIME?

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.

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, ...

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."

[joaotavora]

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.

[joaotavora]

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

#+begin_src lisp :results output
(princ (make-string 400 :initial-element #\A))
#+end_src

This will elide the string indeed

#+begin_src lisp :results output
(make-string 400 :initial-element #\A)
#+end_src

But this is wrong anyway, because in good Lisp REPL tradition, it should return the string braced with quotes, so it is READ able, and this doesn't work for multiple values anyway.

#+begin_src lisp
(values 1 2 3)
#+end_src

#+RESULTS:
: 1

I recommend you use :results :output if you want to output long text. That's what you would do at a REPL anyway.

Anyway, if ob-lisp.el wanted to keep this way of working and not present its users with elided strings, it could use *SLYNK-PPRINT-BINDINGS* easily.

[yantar92]

Anyway, if ob-lisp.el wanted to keep this way of working and not present its users with elided strings, it could use SLYNK-PPRINT-BINDINGS easily.

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.