Hi there, thanks for your efforts, I compiled commit 9226ea543d23 and can say it does work (I didn't look long for any new stuff though).
I may have a biggy, though; I do a lot of Chinese database stuff and pspg is a godsend to me. However I realized that column alignments are regularly out of sync as soon as double-width characters are displayed. I'm not sure but wasn't it the case that they do align just fine, as they do in 'most' (but sadly not in 'less')?
I've been working on so many things in the meantime so my memory could be wrong.
I could supply some test data if you think you might work on that. Double-width characters do work in 'most', as I said, so that is proof it is in principle feasable.
to compile like I did before. Czech chars and everything outside of 7bit ASCII is one problem, but the other one is graphically wide characters.
Some time ago I published https://github.com/loveencounterflow/to-width which uses a bunch of helpful Unicode-aware packages (sindresorhus/string-width and martinheidegger/wcstring which you find on npmjs.org and github) to achieve constant-width output in the presence of mixed narrow (single-cell) and wide (double-cell) codepoints.
I think the screenshot demonstrate quite nicely what I'm talking about. I could give you a bunch of *.sql files to feed into a test database if that is helpful (in case you want to take up the challenge at all).
@PL - It is working somewhere. Looks like not everywhere ncurses mechanism is working. When I call psql and pspg locally, then it is working. When I use ssh it doesn't work. It can be related to ncurses version too.
probably this is a reason. The resizing there doesn't work well when the application is nested. You can try direct call of pspg (without psql) by pspg -f somefile. Is resizing working there?
Here my actions: 1. run select * from pg_class to start pspg 2. Resize terminal window 3. After resizing pspg still correctly working with this query! 4. Stop pspg (by pressing q) 5. Run another query and pspg stops working correctly 6. When restarting psql, pspg works correctly again.
It is strange. Any new query means new instance of pspg. So when you stop pspg, then it is finished, and with new query, then it should to get fresh window size. So it looks like the core of the issue will be else where. What is psql version? Some older psql clients had a issue with resizing.
I tested pspg on an up to date Debian 9 with Pg 9.6. I compiled it with just a simple make. It works as expected. I have found just a small typo: The error message for -s states that there are only 11 colour schemas while in the program there are 12.
Hi there, thanks for your efforts, I compiled commit 9226ea543d23 and can say it does work (I didn't look long for any new stuff though).
ReplyDeleteI may have a biggy, though; I do a lot of Chinese database stuff and pspg is a godsend to me. However I realized that column alignments are regularly out of sync as soon as double-width characters are displayed. I'm not sure but wasn't it the case that they do align just fine, as they do in 'most' (but sadly not in 'less')?
I've been working on so many things in the meantime so my memory could be wrong.
I could supply some test data if you think you might work on that. Double-width characters do work in 'most', as I said, so that is proof it is in principle feasable.
I am using Czech chars in UTF8 encoding and there are not issues, please, recheck - ncursesw should be used if you are using wide chars.
ReplyDeleteI used
ReplyDeletegcc pager.c -o pager -L. -lncursesw
to compile like I did before. Czech chars and everything outside of 7bit ASCII is one problem, but the other one is graphically wide characters.
Some time ago I published https://github.com/loveencounterflow/to-width which uses a bunch of helpful Unicode-aware packages (sindresorhus/string-width and martinheidegger/wcstring which you find on npmjs.org and github) to achieve constant-width output in the presence of mixed narrow (single-cell) and wide (double-cell) codepoints.
I think the screenshot demonstrate quite nicely what I'm talking about. I could give you a bunch of *.sql files to feed into a test database if that is helpful (in case you want to take up the challenge at all).
ReplyDeleteplease, send me a test case. Maybe the issue is on psql side, maybe in psps.
ReplyDeleteHere you go:
ReplyDeletehttps://github.com/loveencounterflow/fwtest
Hope it helps,
cheers
I started new issue - https://github.com/okbob/pspg/issues/19
ReplyDeleteAlthough there are still some artefacts for horizontal scrolling (maybe due wrong calculation display len) it is much better.
ReplyDeleteVery nice. Thanks!
ReplyDeleteIt seems that pspg currently does not handle window resizing.
@PL - It is working somewhere. Looks like not everywhere ncurses mechanism is working. When I call psql and pspg locally, then it is working. When I use ssh it doesn't work. It can be related to ncurses version too.
ReplyDeletePavel,
ReplyDeleteEven when I run locally, it doesn't work for new query after resizing.
What ncurses version do you use? I have not a problem with ncurses 6 - ncurses-6.0-8.20170212.fc26.src.rpm
ReplyDeleteI use libncursesw5-dev on Ubuntu.
ReplyDeleteprobably this is a reason. The resizing there doesn't work well when the application is nested. You can try direct call of pspg (without psql) by pspg -f somefile. Is resizing working there?
ReplyDeleteHm, without psql it working.
ReplyDeleteHere my actions:
1. run select * from pg_class to start pspg
2. Resize terminal window
3. After resizing pspg still correctly working with this query!
4. Stop pspg (by pressing q)
5. Run another query and pspg stops working correctly
6. When restarting psql, pspg works correctly again.
It is strange. Any new query means new instance of pspg. So when you stop pspg, then it is finished, and with new query, then it should to get fresh window size. So it looks like the core of the issue will be else where. What is psql version? Some older psql clients had a issue with resizing.
ReplyDeleteYes, you are right!
ReplyDeleteThe issue on a psql 9.4
With psql 9.6 worked fine.
I tested pspg on an up to date Debian 9 with Pg 9.6.
ReplyDeleteI compiled it with just a simple make. It works as expected.
I have found just a small typo: The error message for -s states that there are only 11 colour schemas while in the program there are 12.