[core.editor] improve first time setup to include Notepad++

[un1versal]

On a Windows system, even though you have setup Notepad++ as default
system editor, Git seems to behave oddly during operations and you may trip over
glitches, like prematurely terminated Git operations before your edits
are complete.
Setting up core.editor in Git explicitly to Notepad++ fixes this behavior.

Related:

• Preview of changes
• Discussion issue #365

[ben]

So Notepad++ is a fantastic editor, but it doesn't come in the box with Git or Windows, so I hesitate to recommend it like this. We don't want the user to have to install 20 things just to follow along with the book. However, given how alien things like Vim and Emacs are on Windows, we need to do something.

What about GitPad? Does that play well with Notepad++? If so, it essentially solves the entire problem: install GitPad, set your favorite editor to be the default for *.txt files, and you're done. Plus we don't have to play favorites with Windows editors.

[un1versal]

Thanks Ben 😄

_We don't want the user to have to install 20 things just to follow along with the book._ However, given how alien things like Vim and Emacs are on Windows, we need to do something.

OK.... but.... mmmm

What about GitPad? Does that play well with Notepad++? If so, it essentially solves the entire problem: install GitPad, set your favorite editor to be the default for *.txt files, and you're done. Plus we don't have to play favorites with Windows editors.

But If I install GitPad, (which also doesnt come out of the box with Windows) that is one more program I have to install that I didn't have before or never used before, so it interesting you first say you dont want people to install 20 things but then find it acceptable if they install 19. BTW Im only installing 2 currently. Github Desktop and Notepad++

Your argument is somewhat conflicted, but if that was a 👎 to this PR then OK consider this my 👎 to the suggestion you made.

I need a powerful editor that does the same job Im used to when I work in Linux where I mostly am, and when I come to Windows I dont want to feel put out by using inferior tools, but at the same time refuse to install just another little program, because someone thinks that is acceptable solution, and I cant very well fix this in git core, I dont have time, skills, or interest.

[ben]

So yeah, I changed my mind in the middle of that comment. It kind of hinges on how many recommendations we're making, and if the only example of configuration on Windows is for an editor the user doesn't have, that's confusing.

Part of the problem here is the way system-wide editors are configured. If you want to change it in a Unix, you set $EDITOR, which Git will honor. If you want to do the same in Windows, you change the editor associated with .txt files, but Git will still use vim. Installing GitPad bridges this gap, and I tend to think that's the way it should work (though I realize others disagree with me).

Here are some options I see:

• Outline the configuration for Vim or Emacs in the main text, and in a [NOTE] section mention Windows configuration, and cover both Notepad++ and GitPad.
• Make a note on GUI editors in general, note that there might be some extra command-line options required to make Git wait for the editor to finish. Mention that the user may want to look into GitPad if they're on Windows.

Does one of those sound okay? Can you think of something better?

[un1versal]

Well, Ill think on this a bit, I hesitate on having to install GitPad + Notepad++ and Git (sigh Im tired now) 😬 or whatever, learn how to that works and document it, but OK, Ill do that also in addition.

Confusing is mentioning Linux/Unix tools and ignoring the poor cousin Windblows. Making recommendations based only on Unix/Linux default editors that re not suitable in Windblows for everyone (note that the majority of users here) the nerd herd is OK with anything and pass GO collect $400.

However, you cant just document programs which are default and used in one particular OS without any issues. Docs exist to explain and help configure things when something is as odd as this. They dont exist to document the obvious stuff which is whats going on here in this example.

---

<rant>
its a pain to have fragmentation in the tools and methods used, but when the core cant handle this in any ideal fashion then you must resort to whatever the path of least resistance is. For most users its just installing the obvious tools and if they fail you look at docs, when docs dont have anything then whats the point or RTFM?
Also for sake of the rant 😁 its 2015 and notepad in Windows still sucks, wordpad sucks more and what choice does anyone who venture in Windows in a sporadic, seldom manner have? Notepad++ or Sublime text, cause the rest is just argh. (Yes We love the smplicity of Unix/Linux but when that translates to the opposite in WIndows you run. (I do)
So 3rd party it is YOU cant have decent editors in Windows by default unless you dont care about making anything easy on yourself.

And again, what a waste of time GitPad, why not just include the improvements into Git Ill never know.

</rant> 👍

---

For that reason I will try to include your suggestions just give me some time but gitpad is last on my agenda and by any means the least favored choice on doc order since its yet some other tool to install.

Lets face this a second, if you came to the point of RTFM regarding this you can very well run the documented git config commands without any noob tools to aid in task.

[un1versal]

Apparently Github Desktop uses GitPad but why if it doesn't work really. (I asked Gihub Support), news to me having dug up the location of this executable now hunting to find the configuration file, This is turning into a scavenger hunt and here was I thinking this was a simple job...

[un1versal]

@ben see github/GitPad#24

Well Im definitely not adding GitPad instructions to this, so it is what it is here until that is resolved.

Its very frustrating, on one hand I have your comments and on the other Github Desktop App which uses GitPad still needs these core-editor additions else GitPad via GitHub Desktop does not work as advertised.

So there it is. Either take these commits or suggest something that doesnt involve gitpad and Ill be happy to change this PR else, close it and damn all users who have this issue to look for solutions for hours on end.

[ben]

Yeah, I see your point. I didn't realize GitPad didn't solve the Notepad++ problem.

We definitely want to document the Vim/Emacs path, since those tools come with Git even on Windows, and give the user some guidance on how to use their favored GUI editor as well. Since this is especially tricky on Windows, we should call it out with a [NOTE] section that mentions some of the difficulties, and shows the correct configuration for Notepad++, Sublime Text, and maybe one of the other popular choices? What do you think of that approach?

[un1versal]

vim or emacs is already documented just needs adjusting the OS warning. Ill adjust this PR to make a note and call attention to the windows issue, and later when I have more time will add sublime text to it as I would have to go find out what it supports in order to document it.

Boy oh boy, do I regret using Windows for 5 minutes. or what.

Once Im done Ill ping you.

[nebasuke]

Also, for people who are using Windows AND Cygwin, which I assume is relatively common when they're using git from the command-line, it might be best to make a note that the stated solution does not work out of the box from Cygwin.

Instead to fix the path problems in Cygwin you will need something like the following:
'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession "$(cygpath -w "$*")"

[un1versal]

If anyone knows what to add for sublime text editor let me know, I dont have time to go learn about some tool I never used to document something here.

Else Ill just document the parts which resolve the issue for users such as myself at this time.

[un1versal]

@ben

I hope this is acceptable.

I also hope Im not expected to document every possible editor and cover scenarios that didn't apply this issue specifically, as that is well outside the scope of this PR.
That was never my intention with this PR, just to make it clear, I wanted to document and improve the immediately available docs to include a solution for the issue.

[ben]

Yeah, let's go ahead with this. It's definitely better, and it doesn't make it hard to include instructions for even more editors. Thanks for this!