Anyone have any recommendations for how to efficiently handle conflicts/reviews via vim with a small screen?
Anyways, you can try a narrow width font: I love M+ 1mn, though the narrow width causes problems when it doesn't have a certain unicode point defined and falls back to a full width font..
Note that OSX by default has some type of feature that reduces the realestate you have available.. don't ask me to explain it, i haven't really used it much.
Basically, with the Retina monitors, the resolution is actually too high for a lot of scenarios. You end up with tiny fonts, tiny icons, etc. So they somehow sample/zoom the sizes so that you get both really crisp renders but with very few real pixels on screen.
This may be what is causing you to be surprised that i am still having issues with a high resolution Retina screen. But, turning it off would be effectively the same thing as just turning my iTerm2 fontsize to ~8-10 or something tiny, allowing me to fit three panes.
Also I often find myself need to copy code from some old revisions, in that case, I just visit our web "IDE", find desired revisions with revision search helper, and open desired symbols to copy relevant code out.
are the main ones, git-time-machine is probably my favorite package period in the Atom ecosystem. As it shows what is possible with completely user created UI.
Shameless plug for a package I wrote too https://atom.io/packages/atom-git-revert which also helps on the daily!
I've found, as the OP did, that the GitHub/Lab/Bucket code review UIs strongly encourage nitpicking over code style and strongly discourage true insightful reviews on a design and architecture level. This happens simply because of the amount of effort your have to do to see and feel the wider impact of a pull request on your codebase. It's like looking at code with blinders on.
So what you want to do is checkout the pull request and use your editor. We made this a habit here at TalkJS and the quality, speed and usefulness of our code reviews skyrocketed.
Actually we take it one step further: we dropped the commenting interface altogether. Our code reviews are commits, with code comments by a particular format:
My colleague Marcin can find all reviews intended for him by grepping for `REVIEW(marcin`. Git ensures that even across merges and code changes, comments stay put, and once Marcin applies the review comment he removes the comment. He can reply by adding a comment in the same format.The fact that review comments are right there in the git history also really helps track down complicated problems. Finally, we get the freedom of merging a PR anyway even though some things ought to be better, without losing track of the review comment. Obviously that's a code smell, but sometimes it's better to release first and refactor next day.
But even if you think this is insane and reviews don't belong in the code, I'd like to warmly encourage you to use your editor for reviews.