You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature or problem you’d like to solve
When you run gh issue comment or gh pr comment, you get a prompt like:
- Press Enter to draft your comment in vim...
The prompt seems like unnecessary friction to me. I'm guessing it's there so people aren't disoriented when gh suddenly launches vim (or whatever their $EDITOR is), but it's annoying to have to press Enter for it every single time I write a comment.
Proposed solution
Remove the prompt. Maybe add a message like "Opening vim to draft comment"? It may not be visible long enough though.
Would passing the -e flag be a sufficient workaround for you? You could alias the command to include -e every time you invoke the alias.
Ah, I didn't realize what that flag was for. (It's a little confusing that the docs for it say "Add body using editor", since that's the default.)
I think having a config setting might be a cleaner approach, but for now I will alias the command.
I think the issue is that many people will not realize you can get rid of the prompt by setting an alias (or a config option if you choose to add one), and they will either just deal with it or open issues. I'm not sure how this could be solved though.
Actually, there's not a way I can change the behavior of gh pr comment (or gh issue comment) using an alias, because I can only add an alias at the top-level; e.g. gh prc. Another reason why a config option might be helpful :)
@camelid You should be able to define an alias in bash or so, like alias gh-pr="gh pr comment -e" no?
But in general the behaviour of hub on creating a PR just seems so much more useful; they start $EDITOR which is prefilled w a text built from the individual commits, and then they take the first line as the PR title and the remainder as the body; they also skip everything after the cut-off line. This is much more git-like then then weird terminal UI of gh
Re-labeled this issue to indicate that we could improve the documentation for the --editor flag to make this more discoverable. Otherwise, I don't think there is anything we need to change with the issue comment command.
Note that we're also considering adding --editor flag to issue create and issue edit commands too: #390 (comment)
Activity
mislav commentedon Feb 2, 2021
Thanks for the feedback. You've guessed our reasoning to avoid launching the editor program unprompted.
Would passing the
-eflag be a sufficient workaround for you? You could alias the command to include-eevery time you invoke the alias.camelid commentedon Feb 2, 2021
Ah, I didn't realize what that flag was for. (It's a little confusing that the docs for it say "Add body using editor", since that's the default.)
I think having a config setting might be a cleaner approach, but for now I will alias the command.
I think the issue is that many people will not realize you can get rid of the prompt by setting an alias (or a config option if you choose to add one), and they will either just deal with it or open issues. I'm not sure how this could be solved though.
camelid commentedon Feb 2, 2021
Actually, there's not a way I can change the behavior of
gh pr comment(orgh issue comment) using an alias, because I can only add an alias at the top-level; e.g.gh prc. Another reason why a config option might be helpful :)radiospiel commentedon Feb 11, 2021
@camelid You should be able to define an alias in bash or so, like
alias gh-pr="gh pr comment -e"no?But in general the behaviour of
hubon creating a PR just seems so much more useful; they start$EDITORwhich is prefilled w a text built from the individual commits, and then they take the first line as the PR title and the remainder as the body; they also skip everything after the cut-off line. This is much more git-like then then weird terminal UI ofghmislav commentedon Feb 9, 2022
Re-labeled this issue to indicate that we could improve the documentation for the
--editorflag to make this more discoverable. Otherwise, I don't think there is anything we need to change with theissue commentcommand.Note that we're also considering adding
--editorflag toissue createandissue editcommands too: #390 (comment)mfilej commentedon Feb 9, 2022
@mislav 👋 Any chance for a mechanism to globally enable the editor option (env variable or config file if there is one)?
(I wasn't aware of
--editoreither, I'm still usinghubto open pull requests. 😅)mislav commentedon Feb 17, 2022
@mfilej No way of making
--editordefault right now; sorry!