On Feb 20, 2020, at 8:35 AM, Manlio Perillo <manlio.peri...@gmail.com> wrote: > > This is not a matter of style. It is a matter of having clean diffs in > commits.
It is both. You may prioritize clean diffs, and I understand your reasons for that. Many other people prioritize readability over clean diffs. Neither side is *wrong*, because it's all subjective, but I think it would be better to get some sense of how it would affect users either way before committing to a path. Otherwise, you will wind up with pitchforks and torches. My belief is that the status quo is actually the best compromise, but I'm willing to be convinced otherwise. However, I'm unlikely to be convinced that a new "magic" tab that won't be supported by the vast majority of existing editors, terminals, printers, browsers and the like is going to be the solution. You could always split the baby and use a default tabstop of, say, 30 or 40 columns and let longer identifiers just run over. That's unlikely to really satisfy anyone, but it's equally unlikely to dissatisfy folks to the extent that changing to a single space will. Note that any change made is going to wind up producing ENORMOUS superfluous diffs the first time anyone uses it on existing code that's already been formatted, not unlike the problem of converting hard tabs to spaces or vice versa, so bear that in mind. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/81701ED1-D431-4B36-8E6D-0E4FF8EB763C%40gmail.com.
