81–90 of 192 posts
Earlier quoted context omitted.
Something like this? https://github.com/jaxbot/semantic-highlight.vim
From reading the README, it just cycles through colors. The colors are random, not semantic, so the name seems to be misleading?
Earlier quoted context omitted.
I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't)…
I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity. Often times I see my coworkers screwing around with git trying to review diffs and commit their changes. One of two things happens: they spend longer than they should doing it, or they do it haphazardly. Sometimes they get it wrong. Just use a GUI. I use Sour…
There are definitely people out there (I've seen them) that would be better served with a GUI because they really can't be bothered to learn how to use the `git` CLI well (Or just use `git` well in general). But at the same time I'm tons more productive with the CLI vs. GUI.
But I can see the benefit of forcing you to make your code more readable in general.
I like to highlight just the places where you are defining new variables/functions/types so that the definition is easy to spot. What is the point of highlighting keywords? I suspect that highlighting engines do it simply because it's easy to do, not because it's useful. It looks like this: http://david.rothlis.net/code_presentation/distracting_synta...
Eclipse - no colors for different things, hard to find what I'm looking for (if I compare to the Emacs example, if I was looking at this code trying to figure out what members this class has I'd be looking for brown and finding it much more quickly)
Emacs - terrible color scheme, both the brown and the green are too bright, not enough contrast to read.
Proposed - all the bold text hurts my eyes and distracts me from everything else.
In my crazy theme almost every "thing" has its own color, and it is very easy to find what I want by looking for the right "thing" or combination of things. As an example for where highlighting keywords would help (which is what you mentioned in your post), if I'm looking for "that for loop that does the main logic" I'd look for the place with the small blue blob on the left and a long bright blob to the right (if it was an "if" likely both blobs would be smaller ;)).
Earlier quoted context omitted.
I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, c…
Don't you always have commits chains like "add debug printfs" "fix bug" "remove debug printfs"?
Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.
Earlier quoted context omitted.
I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, c…
I understand what you're getting at, but unfortunately I just don't write code that way (And I'm not really sure I know tons of people that do). I always end-up making changes or realizing things halfway into working on something. That said I do understand your point, generally what I do is commit 'logical' parts of my work (Generally using `git add -i` to commit individual chunks), and then when I'm done I checkout…
The tricky thing is that when doing several things without committing, sometimes you can end up in a state of the repo where you can't split the work done into nice commits anymore (because you might have modified same part of code multiple times).
Earlier quoted context omitted.
I'm just trying to convince folks to actually write commit messages. :) I don't think anyone is relying on diffs to find bugs. Do they? Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.
I do this, but not mainly to find bugs, though on rare occasions I do. I almost always find something , e.g. stylistic aberrations, overzealous changes from an intellij refactor, debug statements I forgot to remove, part of another change I'd thought I'd stashed but somehow ended up in the commit. It blows my mind that anybody would not read their diffs.
I looked over an old edition of Halliday+Resnick once, a well thought of lower division physics book. The text was substantially the same but it was black and white. This meant no syntax highlighting and also no glossy paper. The result was a LOT easier to read.
Glossy paper is a designery thing to do for deeper blacks but it's less readable. Indeed that's why actual designers like matte finish MBPs, because you don't want to read with a 20% opacity of yourself staring at you.
std::array, max_window_count>{};
s.lines()
.map(|bline| UnicodeSegmentation::graphemes(bline, true)
.collect::>())
.map(|line| wordwrapline(&line, maxline, maxword))
.collect::>()
.join("\n")