On Tue, Jun 7, 2022 at 3:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > The code needs a comment about why it's emitting a newline, though. > In particular, it had better explain why that should be conditional > on !pagerpipe, because that makes no sense to me.
Yeah. OK, here's my take:
+ /* + * If the terminal driver echoed "^C", libedit/libreadline might be + * confused about the cursor position. Therefore, inject a newline + * before the next prompt is displayed. We only do this when not using + * a pager, because pagers are expected to restore the screen to a sane + * state on exit. + */
AFAIK pagers conventionally use something like termcap ti/te[1] to restore the screen, or equivalents in tinfo etc (likely via curses). If we were to inject an extra newline we'd just have a blank line for nothing. I suppose there could be a hypothetical pager that doesn't follow that convention, and in fact both less and pspg have a -X option to preserve last output, but in any case I expect that pagers disable echoing, so I don't think the ^C will make it to the screen, and furthermore ^C isn't used for exit anyway. Rather than speculate about the precise details, I just said "... sane state on exit". Pavel, do you agree?
Applications designed to be used as pager are usually careful about the final cursor position. Without it, there can be no wanted artefacts. pspg should work in pgcli, which is a more sensitive environment than psql.
I think modern pagers like less or pspg will work in all modes correctly. There can be some legacy pagers like "pg" or very old implementations of "more". But we don't consider it probably (more just in comment).
Regards
Pavel
Here's how it looks after I enter and then exit Pavel's streaming pager:
$ PSQL_WATCH_PAGER='pspg --stream' ~/install/bin/psql postgres psql (15beta1) Type "help" for help.
