New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow resizing the commit message area #193

Closed
odrotbohm opened this Issue Jan 18, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@odrotbohm

odrotbohm commented Jan 18, 2018

It would be cool if one could resize the commit message area just like one can the staged files area. Especially if you're crafting more verbose commit messages, being cramped into that narrow little text field feels a bit claustrophobic 😉.

Thanks for the great work!

@DanPristupov

This comment has been minimized.

Contributor

DanPristupov commented Jan 23, 2018

Hi Oliver!

Yes, I agree. Actually I always wanted to do this like you described but never had enough free time :).

I'll try to implement this soon. Hopefully won't get stuck because of the expand/collapse animation.

@DanPristupov

This comment has been minimized.

Contributor

DanPristupov commented Mar 16, 2018

I did not implement resizing yet, but I reworked the commit message area in 1.0.65.
2018-03-16 at 09 28

@nebhale

This comment has been minimized.

nebhale commented Mar 16, 2018

This is hijacking the resizing issue a bit, but this seems like the appropriate place to respond to the commit message area changes.

I need to use it a bit more, but my initial impression of this change isn't great. The biggest issue is that if you try to write a commit message by habit, it's not clear what the result actually is.

screen shot 2018-03-16 at 6 48 39 am

This feels to me like an example of the UI being helpful, but it breaking the expectations of people who've spent time working at the command line.

In the spirit of constructive criticism, maybe what's need is a much more definitive separation between subject and body. Not necessarily two boxes, but boundary lines, automatic trimming of the top empty space, or something along that path.

@DanPristupov

This comment has been minimized.

Contributor

DanPristupov commented Mar 16, 2018

@nebhale Thank you very much for the feedback. I think current issue is a good place to discuss the topic.

The biggest issue is that if you try to write a commit message by habit, it's not clear what the result actually is.

It was the same before. I received feedback that people are not sure how many space will be placed between. It was a bit more clear though.

My personal feeling about new layout is the following: I like where it goes, but the feature is not final yet. Let's try to improve it and if it won't work out fine, I'll revert my changes.

So, the current problems:

It's not obvious how many empty lines will be placed between the subject and body.

We can add a more clear placeholder which will clarify this. Changing Description to Commit description makes it explicit, doesn't it?

need ... much more definitive separation

I can increase the empty space between Subject and Description and also add thin horizontal line.

I'll make a mockup on the weekend...

@DanPristupov

This comment has been minimized.

Contributor

DanPristupov commented Mar 16, 2018

OK, here's how it could look like:
2018-03-16 at 15 52

2018-03-16 at 15 53

@nebhale

This comment has been minimized.

nebhale commented Mar 16, 2018

That would be much more obvious.

The keyboard interaction would be interesting to think about as well. Typing a commit message in a standard text editor would be <SUMMARY TEXT>+ENTER+ENTER+<DESCRIPTION TEXT>. I'm guessing the way the commit box works today is that the same keystrokes result in an extra newline in commit messages. It might be helpful to eat one of those newlines (effectively have it represented by the hairline) as part of the interaction. This way muscle memory doesn't result in a poorly formatted message.

One thing that keeps nagging at me though is the thought that this might be prescribing too much in the UI. The summary + empty line + description is a convention (recommended certainly) but not a requirement. If you chose to buck this convention, say one big paragraph of text with multiple lines but no empty line, how would you even do that with this UI?

@DanPristupov

This comment has been minimized.

Contributor

DanPristupov commented Jul 16, 2018

I made another change related to the description field. It's being resized automatically relying on the inner content up to a half of the screen. I also reduced jumping and blinking on focus.

2018-07-16 at 14 47

2018-07-16 at 14 47

I'm pretty happy with the result and I think we can close the issue once the feature comes out publicly.
You can try it already in this build: http://git-fork.com/update/files/Fork-1.0.68.5.dmg

@DanPristupov DanPristupov added this to the 1.0.69 milestone Jul 19, 2018

@DanPristupov DanPristupov added the done label Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment