Date: Fri, 26 Dec 1997 23:34:06 -0500 (EST) From: Tim Vanderhoek <hoek@hwcn.org> To: Mikael Karpberg <karpen@ocean.campus.luth.se> Cc: Bruce Evans <bde@zeta.org.au>, current@freebsd.org Subject: Re: Bruce vandalism again Message-ID: <Pine.GSO.3.96.971226232310.23218A-100000@james.freenet.hamilton.on.ca> In-Reply-To: <199712270242.DAA13721@ocean.campus.luth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Dec 1997, Mikael Karpberg wrote: > Really, that's so much hard work anyway. Ok, I'm not for making it harder, > doesn't a cdiff program (or option to diff) seem more sane? One that parses > the c code, and ignores inserted/removed empty lines, tabs, spaces, and > comments (possibly changeable with an option so you could get the comment Well, diff --ignore-space-change would be a pretty good start (tabs, spaces, and empty lines :). Removing comments would be a pretty trivial lex program, or there are also a couple of infamous perl regexps which match C comments. To further reduce noise, both bits of code to be diffed could be run through indent first, converting them to a mutually unacceptable but consistent style. This then could all be bundled up into one program `cdiff'. :) > time in c files, as you accidently delete a tab, and replace it with spaces, Well, if you used tabs and spaces in the right places, then this wouldn't be a problem. My rules, #1: never mix tabs and spaces to achieve the desired spacing, #2: never use tabs to align with text that wasn't aligned with the exact same number of tabs. These rules really reduce to: Make no stupid assumptions about the number of spaces in tabs. I edit with 3, 4, and 8 space tabs variously to ensure these rules are met. Needless to say, reading code not my own is always so depressing. -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.971226232310.23218A-100000>