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

Provide custom frame filtering options #37

Merged
merged 8 commits into from May 5, 2020
Merged

Conversation

yaahc
Copy link
Contributor

@yaahc yaahc commented May 1, 2020

closes #25

src/lib.rs Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@yaahc
Copy link
Contributor Author

yaahc commented May 1, 2020

build failing because stable isn't available, nice :)

I did not touch the formatting stuff, it should be ready for you to add the fancy pre/post frame filtering though

@athre0z
Copy link
Owner

athre0z commented May 2, 2020

Thanks for the great PR. I really didn't have to change a lot!

For the spacers, I tried different things and thought that it would be cool to go with the zig-zag look that GitHub does when it truncates an enormously long issue:

Zg9qoS9mLXv9stpq

That's what it looks like with my current glyph selection in iTerm:

TBh1NUeHLFthbF2Z

I think it's okay, but I'll look into other glyphs.

Alternatively, with the glyph I originally proposed:

q5THIHQY4kLTJ792

@yaahc
Copy link
Contributor Author

yaahc commented May 2, 2020

I'm not sure if it just takes some getting used but rn I think I prefer the second option

@athre0z
Copy link
Owner

athre0z commented May 2, 2020

Yeah, I'd go with the second one of those two as well. There's a quite significant lack of unicode characters for displaying medium height wavy/zigzag horizontal lines. I found two more options:

iTerm
Screen Shot 2020-05-02 at 15 14 56

Gnome Term
Screen Shot 2020-05-02 at 15 36 12

Screen Shot 2020-05-02 at 15 26 26

Screen Shot 2020-05-02 at 15 31 56

None of them is really just perfect. I'd say we go either with the second option in this post or the simple from the previous post.

@yaahc
Copy link
Contributor Author

yaahc commented May 2, 2020

Sounds good, I agree with you that the second option here also looks pretty good but I don't have a strong preference.

@athre0z
Copy link
Owner

athre0z commented May 2, 2020

Alright, I just went with the somewhat more conservative for now. I'll test out some more options and maybe make it configurable & launch a Twitter poll for the default later, but don't want to block this any longer. Additionally, I migrated the CI to GH Actions, which seems to be working fine.

Did I forget anything? From my side of things, this should be ready to merge.

@yaahc
Copy link
Contributor Author

yaahc commented May 4, 2020

Nope, I think this ones good for me, also if you can make a release with this once it's merged I would be eternally grateful.

@athre0z athre0z merged commit d8660e9 into athre0z:master May 5, 2020
@athre0z
Copy link
Owner

athre0z commented May 5, 2020

I'll do a release tomorrow, after doing some additional testing. I want to make sure that no off-by-ones wre introduced -- having the wrong frames hidden would be a really major PITA for everyone trying to debug their app using the lib.

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

Successfully merging this pull request may close these issues.

Provide custom frame filtering option
2 participants