[vim/vim] The man page opened via ShKeywordPrg doesn't close upon hitting q (Issue #21204)
Enrico Maria De Angelis
Aster89 created an issue (vim/vim#21204)Steps to reproduce
Assuming you have a ~/.bash_profile, run vim --clean ~/.bash_profile, then move to a keyword and press K. I think it's fundamental that the man page of that keyword is longer than the space available in the window that will open up.
The pager will open up in a terminal split window via this line
https://github.com/vim/vim/blob/5c9c5a43c183e8d1e4156b468343d0aa0f3b081c/runtime/ftplugin/sh.vim#L58
Now, press q to close it.
Expected behaviour
I'd expect the split window to close entirely, but it isn't. It becomes empty, though.
Version of Vim
Environment
Operating system: up-to-date ArchLinux
Terminal: URxvt
Value of $TERM: rxvt-unicode-256color
Shell: Bash
Logs and stack traces
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#21204)It's a normal split window, you shouldn't expect q to close it. It seems like you'd rather prefer the non-terminal version of this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Enrico Maria De Angelis
Aster89 left a comment (vim/vim#21204)Well, in a normal spit window q does not what it does here, right? I'm not claiming q should close split windows. I'm just saying that here the split window is used to show a man page, so I'd expect that the necessary mapping would in place for doing the right thing. There's no reason, I think, why I'd want that split window to remain open and empty after I pressed q.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#21204)What mapping are you talking about? In a normal split window, q does nothing, unless you have it mapped it to some function.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#21204)Well, in a normal spit window q does not what it does here, right? I'm not claiming q should close split windows. I'm just saying that here the split window is used to show a man page, so I'd expect that the necessary mapping would in place for doing the right thing. There's no reason, I think, why I'd want that split window to remain open and empty after I pressed q.
If I press q there, it just waits for the register to save macro recording as it should if there was no user q mapping defined.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Enrico Maria De Angelis
Aster89 left a comment (vim/vim#21204)It's a normal split window, you shouldn't expect
qto close it.
In a normal split window, I don't expect q to close it. I expect q to do what it always does, which is
just waits for the register to save macro recording
But in a split window opened via Shift+k in ~/.bash_profile on a word that a man page long enough, q doesn't do that. In this case q quits the pager.
Yes, it does that not because of a mapping, but simply because that's a terminal window where man is run, and q is doing what it does in that case.
What I'm saying is that the behavior of quitting the man page without also closing the split window is not useful, because the surviving empty window has no use. So I'm suggesting that we should conjure a way to have that terminal window to be automatically closed when the pager quits.
Just in case we are not on the same page about what I'm observing, below is a screencast recorded with asciinema:
plus a version of it recorded as a GIF, where you can also see the keystrokes:
Image: Image (view on web)(I've verified that the behavior would be the same if I had passed the --clean flag, even if that's not what I've done when I recorded.)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#21204)command! -buffer -nargs=1 ShKeywordPrg call term_start(['bash', '-c', 'help "$1" 2>/dev/null || man "$1"', '--', <q-args>], {'term_finish': 'close'})
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Maxim Kim
habamax left a comment (vim/vim#21204)you can go another way:
command! -nargs=1 ShKeywordPrg call term_start(['bash', '-c', 'help "$1" 2>/dev/null || man "$1" | col -b', '--', <q-args>])
and then have a mapping for a terminal buffer to quit on q:
au TerminalWinOpen * nnoremap <buffer> q <cmd>bd<cr>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#21204)ping @Konfekt
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Enno
Konfekt left a comment (vim/vim#21204)Happy to go with @habamax's
command! -nargs=1 ShKeywordPrg call term_start(['bash', '-c', 'help "$1" 2>/dev/null || man "$1" | col -b', '--', <q-args>])
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.