You're absolutely right, but I think that saying "requires OS X 10.10 - macOS 10.12," or "requires OS X 10.10 - 10.11, or macOS 10.12 or higher" sound weird.
Apple docs have references to eg: "macOS 10.8+" regarding SDK version. This may still be up in the air, but I predict it will be natural eventually to just use macOS everywhere.
Wow really? I've never seen that in user facing information (eg they kept using "Mac OS X" for older versions when they dropped the "Mac" a few years ago
"<escape> colon w q <return>" is too many 'actions' for me personally (and anything that needs me to reach to escape is really asking for it), and I sometimes even mess that combination up (I used vim before using Komet). I learned about :x recently which is only just slightly better, but not in my muscle memory yet. Then one may need to decide when to use q! or cq to discard..
I also prefer using a native editor and am more productive with spell checking and auto correction, surprisingly.
edit: I'm also not a user that uses the keyboard all the time. After using Komet, I am surprised how often I actually used the mouse to hit commit instead.
I use Vim for regular development and has mapped <Space> to colon in normal mode, so for me it feels very much like a single action to just tap those three keys in quick succession with different fingers on one hand then tapping <Enter> with the other hand. It's like executing a fighting-game combo, the muscle memory makes it feel like a single action even though you're hitting several keys.
But it's arguably true that Vim is the wrong choice as the default commit editor since the majority of users probably will not feel very comfortable in that environment. In hindsight, nano would probably have been the better choice for default.
However, since I'm already a heavy Vim user (and have the vim-fugitive plugin installed), I would never go for anything else.
I have invoked '<escape>:wq<return>' many times; it should be in my muscle memory but it's still something I get wrong on occasion. I can definitely see <space> being better than colon (it gets rid of shift!), although I still have beef with escape. I don't want to play the fighting game :).
What about canceling commits? Sometimes you want to quit without saving, and other times you want to exit with a failure status (which has little application elsewhere). A "commit" editor should be smart enough to decide which to do under a single action.
I acknowledge this isn't intended for those heavily invested in their CLI editor of choice.
Sure, but why would one remember that if they could just do :q! regardless if there's new unsaved content or not.
Relatedly, why would one remember to do :q! or :cq depending on if there's pre-existing content if they can just cancel in Komet and have it do the right thing ;)
I'll take four keystrokes over <move hand to mouse>, <move mouse to button>, <click button> (and a debatable <move hand back to keyboard>). Even if you count that as 3v4, the keystrokes are quicker than the mouse movements.
I get that not everyone wants to deal with vim, and may use a GUI editor for other stuff - but for something as small and specific as git commits, I really don't understand why you'd want to install something new; for what, a button?
:q! quits without saving the text file which only aborts a commit if the message is empty, meaning it's not sufficient if the message has pre-existing content when you open it.
And you largely misunderstood. Komet has a shortcut for making the commit (command return). The mouse is just a supplemental possibility....
Having a more convenient shortcut is not the only reason I use Komet.
[edit]: and to address for "something as small as commits" -- well, I write commits pretty often. So it matters a great deal to me to have an aiding tool, and definitely not for a task I'd consider 'insignificant'
Not currently in my muscle memory but this does interest me since I use vim sometimes for other ocassions. I'd prefer if shift wasn't necessary though... so I'm not sure I'll commit to this :).
Still, these are worse than Mac shortcuts that Komet uses IMO, and I dislike escape (and control to a lesser extent) :-).
Also you sometimes want to quit with an exit failure status on canceling, and why have two different operations for that when your editor is smart enough to have one.
Yes, very arguable :). Komet has keyboard shortcuts. I don't mention them on GitHub because they're shown and I believe natural to figure out after opening the app.
I spend a lot of time on my computer not having at least one of my hands on the keyboard. Say I'm about done writing a commit message but I get a message on my phone I want to quickly check. It may be more convenient for me to use the mouse to hit commit later and then do some browsing tasks, or so. The other day I was doing some refactoring work while eating food in my other hand..
Nonetheless I believe having the option to use the mouse is better than not being able to.
Tried this before making Komet but from what I tested I found this to be slow (stuck in save-and-close model) and obstructive (can bring other sublime documents active).
Not sure how that is better than rendering the editor in the terminal. It's not like you can use that terminal for anything else anyways because it's now waiting for that GUI editor to close.
31 comments
[ 3.0 ms ] story [ 73.6 ms ] threadRegardless, this app is quite nice.
I say that I predict using macOS will be "natural", although that doesn't necessarily mean it'll be "technically correct" for older versions.
I also prefer using a native editor and am more productive with spell checking and auto correction, surprisingly.
edit: I'm also not a user that uses the keyboard all the time. After using Komet, I am surprised how often I actually used the mouse to hit commit instead.
But it's arguably true that Vim is the wrong choice as the default commit editor since the majority of users probably will not feel very comfortable in that environment. In hindsight, nano would probably have been the better choice for default.
However, since I'm already a heavy Vim user (and have the vim-fugitive plugin installed), I would never go for anything else.
What about canceling commits? Sometimes you want to quit without saving, and other times you want to exit with a failure status (which has little application elsewhere). A "commit" editor should be smart enough to decide which to do under a single action.
I acknowledge this isn't intended for those heavily invested in their CLI editor of choice.
Relatedly, why would one remember to do :q! or :cq depending on if there's pre-existing content if they can just cancel in Komet and have it do the right thing ;)
I'll take four keystrokes over <move hand to mouse>, <move mouse to button>, <click button> (and a debatable <move hand back to keyboard>). Even if you count that as 3v4, the keystrokes are quicker than the mouse movements.
I get that not everyone wants to deal with vim, and may use a GUI editor for other stuff - but for something as small and specific as git commits, I really don't understand why you'd want to install something new; for what, a button?
And you largely misunderstood. Komet has a shortcut for making the commit (command return). The mouse is just a supplemental possibility....
Having a more convenient shortcut is not the only reason I use Komet.
[edit]: and to address for "something as small as commits" -- well, I write commits pretty often. So it matters a great deal to me to have an aiding tool, and definitely not for a task I'd consider 'insignificant'
Still, these are worse than Mac shortcuts that Komet uses IMO, and I dislike escape (and control to a lesser extent) :-).
Also you sometimes want to quit with an exit failure status on canceling, and why have two different operations for that when your editor is smart enough to have one.
I spend a lot of time on my computer not having at least one of my hands on the keyboard. Say I'm about done writing a commit message but I get a message on my phone I want to quickly check. It may be more convenient for me to use the mouse to hit commit later and then do some browsing tasks, or so. The other day I was doing some refactoring work while eating food in my other hand..
Nonetheless I believe having the option to use the mouse is better than not being able to.
[0] Up to date fork: https://rowanj.github.io/gitx/ [1] Original: http://gitx.frim.nl/
(personal nitpick: I'd love if the app showed me how to use it rather than having to consult to online instructions)