Closed lervag closed 2 months ago
Perhaps we could also trim spaces in the result window and in the call log?
@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?
Yes, sure:
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:
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.
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)?
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!
No worries - it's already in #98.
Thanks!
I noticed the same untrimmed behaviour in the dbee-call-log:
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.
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.