Skip to content
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

Is it supported/supportable for 'width' to truncate instead of wraping? #3

Open
entity279 opened this issue May 29, 2017 · 2 comments

Comments

@entity279
Copy link

entity279 commented May 29, 2017

def apply(x: Any, width: Int = defaultWidth, height: Int = defaultHeight, indent: Int = defaultIndent, initialOffset: Int = 0): fansi.Str =

My usage is that i have case classes with some junk fields (even binary data). When printing them, i'd rather pprint truncate the field so it doesn't use up the vertical space.

I see that output can be shortened by restricting the number of lines, i'd like it to also be shortened by the number of collumns

@lihaoyi
Copy link
Member

lihaoyi commented Jul 1, 2017

Seems plausible; we'd need some way to tell PPrint which fields to truncate and which to wrap, since I assume you don't want to just truncate everything (which is doable with width = 99999 and String#take).

Perhaps we could provide an annotation that the case classes could use, use java-reflection to perform this task on Scala-JVM, and just not support it on Scala-JS? Or we could provide a trait you inherit to disable wrapping for a particular type, but that won't work for fields of a type you don't control

@entity279
Copy link
Author

Actually for now for my use, truncating everything would do just fine. But I do agree that generally this is a too inflexible approach.

So, wrt truncating only some fileds : I'd prefer something that could work at pprint's call site, rather than having to reference pprint in my unrelated type definitions.
That would involve designating some fields or some field types to be width-truncated via reflection.
This designation could happen at every call or by configuration (I see pprint has a configuration parameter already).
Does this sound to silly a usage?

I can imagine that my preference above could change pprint's interface too much (also, rather clumsy) so an annotation-based implementation is also fine by me; surely I can't comprehend all the tread-offs involved just yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants