Ability to configure a default editor for use with gh

Describe the feature or problem you’d like to solve

I used gh pr create (surprised that it defaulted to open my PR from a fork into the upstream repo - it was awesome🤩) and when I went to edit the PR body, it defaulted to nano but I'd prefer it to use vim.

Proposed solution

When a user first install gh prompt them to choose a default editor:

nano
vim

Let a user specify editor

gh set-editor vim

How will it benefit CLI and its users?

it will support nano and vim users ❤️

Additional context

N/A

we can set the EDITOR environment variable to vim, see

cli/pkg/surveyext/editor.go

Lines 32 to 34 in c03b0d1

    
           if e := os.Getenv("EDITOR"); e != "" { 
        
           	editor = e 
        
           }

Currently our hope is users set EDITOR in their environment (I use and <3 vim and that's what I do for pr create); we default to nano in the hope that it would be less surprising for people new to editing on the terminal.

That said, I think this issue highlights that we should be explicitly documenting use of EDITOR and should call it out:

in the README or similarly visible place
in the help output for gh pr create and gh issue create

nano is not default installed in some distros, vi/vim is more a default than vi/vim for developers, we should move nano --> vi/vim

I would like to set EDITOR on my .bashrc but got thinking is way to generic, it may be more app specific something like GH_EDITOR you never know if other app is looking for the same ENV VAR. and is better to track your ENV's (I have way to much now and is hard to know why they are there)

@ArangoGutierrez

@ArangoGutierrez

nano is not default installed in some distros, vi/vim is more a default than vi/vim for developers, we should move nano --> vi/vim

Yeah that's true & I'm myself a strong vim user, but users might very likely get stuck if they're new to vi/vim, as mentioned be @vilmibm, & I think that the default here is good.

I think it would make most sense to honour GIT_EDITOR since that is likely what people will have set if they are already using vim for editing git commit messages. Using VISUAL and EDITOR can have other non-desired side effects, for example causing bash to work in vi mode instead of emacs mode. What I generally do is look for: GIT_EDITOR then VISUAL then EDITOR in that order, and if none of those are set, use a sane default. https://www.git-scm.com/book/en/v2/Git-Internals-Environment-Variables

@gabeguz

++ to @gabeguz idea

@gabeguz

@gabeguz @ArangoGutierrez done #329

@jsjoeio

@jsjoeio I'm curious if @ahmedelgabri's fix in #329 properly satisfies your use case, or if you think an explicit way to set the editor in gh would still be an important piece. It strikes me as something that might be useful down the road, but given that you can specify your preferred default in your environment, I'm inclined to think we should wait for more feedback on this before pursuing something with more UX around it and that maybe #329 should close this issue for now. Thoughts?

@billygriffin

@billygriffin I think that makes sense. I agree with his point (I've already set that to vim) and I assume most people will too so I think that fulfills my case.

Although, I do believe documentation is super important so it would be a good idea to document how it works (so people don't have to dig through issues/prs/code to see implementation).

Don't know if that should fall under this issue or be a separate issue. Feel free to close this if you think we're good!

@jsjoeio

I like the distinction you drew, thanks @jsjoeio. I updated the title to clarify that this is purely a documentation task. Thanks a bunch for your feedback thus far, it's been really helpful - and thanks @ahmedelgabri for such a quick PR to improve things!

Since this issue is more active than #372, and this is something we're still seeing a lot of despite it now being documented (https://cli.github.com/manual/installation) and respecting environment variables, we think it's reasonable to change the scope of this issue to have more of a first class experience, as originally suggested and as suggested in #372.

I'm going to update the title and we'll look at it in the context of #622 where we're thinking about other things that we'd like to make configurable.

One consideration I was thinking about is what happens if what's specified in the environment variables clashes with what's in the config. I assume we'd use the config first and then fall back to environment variables, but just something to consider in implementation.

Okay sorry, you implemented a way to set it:

cli/command/config.go

Line 52 in 80d7513

$ gh config set editor vim

Thank you, it works now via gh config set editor vim.

@kud

I wanted to follow up on this. With 0.7 you can now set an editor within gh, like @kud describes above. Here are the docs on how that works: https://cli.github.com/manual/gh_config

@kud

@kud The new config value gh config set editor ... is the right way to do this since 0.7; however, without any editor being configured, the EDITOR environment variable should still be picked up and respected. I'm not sure how EDITOR=vim gh issue create did not work for you.

@mislav

To be honest, @mislav, my config at first is export EDITOR=subl and it never opens subl too, haha. So yeah I don't know. 😬

My config : https://github.com/kud/my/blob/master/dotfiles/.zshrc

@kud

@kud Your setup looks fine to me! Generally, if nothing is set as gh config get editor and you have EDITOR exported in your shell, the EDITOR value should absolutely get picked up and used on a non-Windows platform. Since that doesn't happen for you, I encourage you to open a new bug report.

In your report, please also include the values of GIT_EDITOR and VISUAL environment variables. If you have the time and the will to add some debugging statements to Go code, you can try sprinkling some fmt.Println statements here

cli/pkg/surveyext/editor.go

Lines 25 to 35 in a7931a0

    
           func init() { 
        
           	if runtime.GOOS == "windows" { 
        
           		defaultEditor = "notepad" 
        
           	} else if g := os.Getenv("GIT_EDITOR"); g != "" { 
        
           		defaultEditor = g 
        
           	} else if v := os.Getenv("VISUAL"); v != "" { 
        
           		defaultEditor = v 
        
           	} else if e := os.Getenv("EDITOR"); e != "" { 
        
           		defaultEditor = e 
        
           	} 
        
           }

and running make && bin/gh issue create to see what's up.

Thank you!

When I do:

func init() {
	if runtime.GOOS == "windows" {
    fmt.Println("windows")

		defaultEditor = "notepad"
	} else if g := os.Getenv("GIT_EDITOR"); g != "" {
    fmt.Println("GIT_EDITOR")

		defaultEditor = g
	} else if v := os.Getenv("VISUAL"); v != "" {
    fmt.Println("VISUAL")

		defaultEditor = v
	} else if e := os.Getenv("EDITOR"); e != "" {
    fmt.Println("EDITOR")

		defaultEditor = e
	}

  fmt.Println(defaultEditor)
}

I've got:

$ make && bin/gh issue create
VISUAL
nano

So I tried

echo $VISUAL
nano

That's why.

I never set nano as $VISUAL anywhere but it sounds to be like it's by default.

So this is the reason.

Maybe I should set subl for $VISUAL and vim for $EDITOR. And set vim for gh.

@kud

@kud Glad you solved it! 🎉

So whilst this issue is closed, I encountered an issue whilst trying to modify things - like creating issues, adding PR comments - today, and thought I'd share my experience for others who might stumble here.

I tried to configure my editor (using gh config set editor vim), but every time I went to a step which triggered it to open, I was met with:

? What would you like to edit? Body? Body [(e) to launch vim] exec: "vim": executable file not found in $PATH
... a few moments later...
? Body [(e) to launch code --wait, enter to skip] exec: "code": executable file not found in $PATH

Trying a few different options, even the one from here (https://cli.github.com/manual/gh_config_set), all of them returned a similar error state. It was until I uninstalled the 'snap' version of the package and installed any of the other recommendations here (https://github.com/cli/cli/blob/trunk/docs/install_linux.md), it worked as expected, with no further issues.

I'm glad I noticed this whilst looking at alternative install options:
https://github.com/cli/cli/blob/trunk/docs/install_linux.md#snap-do-not-use
then casperdcl#7

tl;dr don't use the snap package - it has issues, and is not recommended anyways.

Am I right that in Windows it's always going to be "notepad"? ☹

@fkthat Absolutely not. The default editor on Windows is notepad.exe. You can change that with environment variables GH_EDITOR, VISUAL, and EDITOR, or by setting gh config set editor "C:\Path\to\myeditor".

Note that because Windows paths typically have spaces, you have to additionally quote any such path within the editor string. Often that will require you to have nested quotes (e.g. double quotes within single quotes). Note that Windows can mangle double quotes appearing within values (I am not aware of a workaround).

@mislav

@mislav , the environment variables (at least EDITOR) doesn't seem to work, but 'gh config set editor' is absolutely OK, however it looks like it should be typed as either C:\\Path\\to\\myeditor.exe (with a double backslash) or C:/Path/to/myeditor.exe (with a forward slash) - this way it's all right. Thanks a lot.

Ah, my apologies. It seems I was looking at the old version of the code that manages environment variable. You are right that environment variables EDITOR and VISUAL are ignored on Windows 😕

cli/pkg/surveyext/editor.go

Lines 22 to 30 in 8272035

    
           if runtime.GOOS == "windows" { 
        
           	defaultEditor = "notepad" 
        
           } else if g := os.Getenv("GIT_EDITOR"); g != "" { 
        
           	defaultEditor = g 
        
           } else if v := os.Getenv("VISUAL"); v != "" { 
        
           	defaultEditor = v 
        
           } else if e := os.Getenv("EDITOR"); e != "" { 
        
           	defaultEditor = e 
        
           }

GH_EDITOR might still work due to it being respected elsewhere regardless of plaform.

This is not working for me on fedora:

OS: Fedora Linux 37 (Workstation Edition) x86_64
Kernel: 6.2.14-200.fc37.x86_64

$ gh config get editor     
subl

But still when I do:

$ gh pr status

The pr status is opened in vim :(

@Vyom-Yadav

@Vyom-Yadav The editor config is only respected in commands that offer you to edit some text. Typically those are create and edit commands, but gh pr status does not invoke an editor. It does pass its output to the PAGER program, so you can check your echo $PAGER or echo $GH_PAGER setting to see if vim is configured there.

Navigation Menu

Repository navigation

Ability to configure a default editor for use with `gh` #308

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	func init() {
	if runtime.GOOS == "windows" {
	defaultEditor = "notepad"
	} else if g := os.Getenv("GIT_EDITOR"); g != "" {
	defaultEditor = g
	} else if v := os.Getenv("VISUAL"); v != "" {
	defaultEditor = v
	} else if e := os.Getenv("EDITOR"); e != "" {
	defaultEditor = e
	}
	}

Ability to configure a default editor for use with gh #308

Description

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Activity

gchiam commented on Feb 5, 2020

vilmibm commented on Feb 5, 2020

ArangoGutierrez commented on Feb 5, 2020

ArangoGutierrez commented on Feb 5, 2020

kiprasmel commented on Feb 6, 2020

gabeguz commented on Feb 7, 2020

ArangoGutierrez commented on Feb 7, 2020

ahmedelgabri commented on Feb 7, 2020

billygriffin commented on Feb 7, 2020

jsjoeio commented on Feb 7, 2020

billygriffin commented on Feb 7, 2020

billygriffin commented on Mar 9, 2020

11 remaining items

kud commented on Apr 23, 2020

billygriffin commented on Apr 23, 2020

mislav commented on Apr 23, 2020

kud commented on Apr 23, 2020

mislav commented on Apr 24, 2020

kud commented on Apr 24, 2020

mislav commented on Apr 24, 2020

keevan commented on Dec 14, 2021

nrju commented on Dec 21, 2021

mislav commented on Dec 21, 2021

nrju commented on Dec 21, 2021

mislav commented on Dec 21, 2021

Vyom-Yadav commented on May 14, 2023

mislav commented on May 14, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Ability to configure a default editor for use with `gh` #308