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

[bug] Use empty lines in drawer #101

Closed
lervag opened this issue Apr 14, 2024 · 9 comments · Fixed by #98
Closed

[bug] Use empty lines in drawer #101

lervag opened this issue Apr 14, 2024 · 9 comments · Fixed by #98

Comments

@lervag
Copy link

lervag commented Apr 14, 2024

This is a minor nitpick: The lines between the sections in the drawer are not empty, instead they contain 5 spaces. This breaks the { and } standard navigation. Although it is minor, it does impact the user experience for people like me who often use this form of motion.

@lervag
Copy link
Author

lervag commented Apr 14, 2024

Perhaps we could also trim spaces in the result window and in the call log?

@kndndrj
Copy link
Owner

kndndrj commented Apr 15, 2024

@lervag hey, I agree with the first suggestion (it's just a consequence of indent rule), but I'm not sure where is whitespace in result and call log. Can you maybe share a screenshot?

@lervag
Copy link
Author

lervag commented Apr 15, 2024

Yes, sure:

image

Notice the highlighted spaces above "help" and above "persistence.json".

Also, I'm curious to know why you might not agree with the second suggestion. This is an example of the type of spaces I propose that we trim:

image

@kndndrj
Copy link
Owner

kndndrj commented Apr 23, 2024

hey @lervag, thanks for the screenshots.
Not that I disagree with your second point, it's just that those trailing spaces are added by an external go library. I'll still look if there's anything I can do though.

The first point is fairly easy to address though :).

edit: just checked docs of the go package and it appears that the matter of addressing the second issue boils down to just a single flag :D.

@kndndrj kndndrj mentioned this issue Apr 23, 2024
@lervag
Copy link
Author

lervag commented Apr 23, 2024

hey @lervag, thanks for the screenshots. Not that I disagree with your second point, it's just that those trailing spaces are added by an external go library. I'll still look if there's anything I can do though.

I would think it should be easy to e.g. run a command like :%s/\s\+$// after filling the buffer? E.g., it seems the result buffer is updated in ResultTile:display_result and that the content is filled with call_display_result. You could add e.g. vim.cmd [[:%s/\s\+$//]] to trim the result.

I also assume that it could be not too hard to patch the go library? It seems much of the go code is part of the nvim-dbee repo as well? I don't know Go myself, but I would assume that one could apply some kind of trim() function to the parseSchemaFul function (and similar)?

@lervag
Copy link
Author

lervag commented Apr 23, 2024

hey @lervag, thanks for the screenshots. Not that I disagree with your second point, it's just that those trailing spaces are added by an external go library. I'll still look if there's anything I can do though.

The first point is fairly easy to address though :).

edit: just checked docs of the go package and it appears that the matter of addressing the second issue boils down to just a single flag :D.

Wow, sorry, I didn't notice this before posting - sorry. But glad to hear that this may be possible and not hard!

@kndndrj
Copy link
Owner

kndndrj commented Apr 23, 2024

No worries - it's already in #98.

@lervag
Copy link
Author

lervag commented Apr 23, 2024

Thanks!

@lervag
Copy link
Author

lervag commented Apr 23, 2024

I noticed the same untrimmed behaviour in the dbee-call-log:

image

This is very nitpicky of me, I know - sorry, but I do think the using trimmed output does increase the general robustness and quality.

Let me know if you want a new issue for this.

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 a pull request may close this issue.

2 participants