Hacker News Reader

Comment by nostrademons | Hacker News Reader

I usually try to fix as many errors as I can identify before recompiling. And yes, I usually fix from the bottom up, because that way my changes don't alter the line numbers of future fixes. On large projects, recompile time can be significant.

View on HN

Yes, sure, large projects can take time to compile, but doesn't your compile environment just try to recompile the last file that it failed on during the build? That is, if in trying to build my app FooBar, and foo.c compiles ok but bar.c fails, when I try to run the build the next time having modified bar.c, it starts by trying to compile bar.c anyway... So I guess what I'm trying to say is that I don't understand the advantage you are apparently getting by woring from bottom up.

I don't want to get into the specifics of the build system since it's proprietary, but there's a non-trivial startup cost for it. It's optimized for being able to compile really huge projects in a tractable amount of time, not being able to recompile individual files in the shortest possible amount of time. The latter will execute quickly enough (yes, it only recompiles what you've changed), but the startup time is still annoying enough to want to batch up edits.

I think you need to upgrade you editor. For instance both vim & emacs are smart enough to adjust for inserts and removals.

I use vim. How do I get it to adjust for edits?

If you are using :make, and _don't_ jump out of the file (split the window if you need to jump out), line deletions and additions down the window are automatically accounted for.

As for turning it on or off, I've never had too, unless it's part of cindent.

Use the :make command so that vim knows about the errors. Then use :clist to list errors, :cnext to go to the next error, etc. :help clist and :help make will get you started.

Reply on news.ycombinator.com