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

Screen not cleared after quitting F1 man #7863

Closed
YaLTeR opened this issue Mar 25, 2021 · 12 comments
Closed

Screen not cleared after quitting F1 man #7863

YaLTeR opened this issue Mar 25, 2021 · 12 comments

Comments

@YaLTeR
Copy link

YaLTeR commented Mar 25, 2021

fish, version 3.2.1, same issue with default config.

On VTE, xterm, urxvt, Konsole (but not Alacritty) exiting the F1 man page with q doesn't move the prompt down and leaves the text on screen, so subsequent commands will overlap with this text.

image

asciinema recording

I made a VTE issue where the maintainer came to the conclusion it is an issue with the sequence fish uses:

Hmm. So this exits the alternate screen via RM_DEC 1049 which does not clear the screen. So unless the result differs between vte and xterm, this is a problem in alacrity.

@zanchey
Copy link
Member

zanchey commented Mar 25, 2021

fish doesn't send this sequence, it is most likely your pager. The output of echo $MANPAGER $PAGER might be helpful.

@YaLTeR
Copy link
Author

YaLTeR commented Mar 25, 2021

fish doesn't send this sequence, it is most likely your pager. The output of echo $MANPAGER $PAGER might be helpful.

Empty in both Alacritty and VTE.

@faho
Copy link
Member

faho commented Mar 26, 2021

I made a VTE issue where the maintainer came to the conclusion it is an issue with the sequence fish uses:

fish does not use the sequence here, your pager does.

It appears man uses less if $PAGER and $MANPAGER are unset, so I'd look at $LESS for any options you've set.

Either way, this isn't a fish issue, we just call man.

@faho faho added the question label Mar 26, 2021
@YaLTeR
Copy link
Author

YaLTeR commented Mar 26, 2021

It appears man uses less if $PAGER and $MANPAGER are unset, so I'd look at $LESS for any options you've set.

Also empty.

Either way, this isn't a fish issue, we just call man.

Executing the man command regularly and quitting out clears the screen, however using fish's F1 doesn't for some reason.

@YaLTeR
Copy link
Author

YaLTeR commented Mar 27, 2021

Here's a script(1) recording of opening and closing man by itself, then opening and closing man using F1.

regular-then-fish.log

@faho
Copy link
Member

faho commented Mar 27, 2021

Lovely: Apparently less won't use/clear the alternate screen if stderr isn't connected to a terminal.

See e.g. less file 2>/dev/null.

In this case we want stderr to be silenced because we don't actually know if the man page exists.

I'm not sure what the alternative is.

@YaLTeR
Copy link
Author

YaLTeR commented Mar 27, 2021

See e.g. less file 2>/dev/null.

Yep, that also reproduces the issue.

@faho faho closed this as completed in 1705bd1 Mar 27, 2021
@faho
Copy link
Member

faho commented Mar 27, 2021

Turns out the alternative is awful:

    if man thing &>/dev/null
       man thing

But still less awful than us e.g. forcing the alternate screen with tput smcup, tput rmcup.

@YaLTeR
Copy link
Author

YaLTeR commented Mar 27, 2021

Seems like it works fine after that commit, thanks!

@faho faho added enhancement and removed question labels Mar 27, 2021
@faho faho added this to the fish 3.3.0 milestone Mar 27, 2021
@faho
Copy link
Member

faho commented Mar 27, 2021

This could be caused by gwsw/less@4d4e6f4 checking fd 2 for the tty to connect to. That means if you redirect fd 2 less won't believe it's in a terminal in some parts (but it obviously handles input and normal output, so it seems to be inconsistent).

I believe this is a bug in less (it's checking a different fd than it is writing to!), if anyone wants feel free to report it.

@zanchey
Copy link
Member

zanchey commented Apr 7, 2021

Reported and fixed.

@YaLTeR
Copy link
Author

YaLTeR commented Apr 7, 2021

Cheers!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants