Thanks for the report, obviously this is my bad (as you noted this appeared in revision 816 and you can clearly see I'm the one who committed that revision). As for why so many files were changed and this problem happened, it is quite simple, I overhauled the #includes and debug defines so that all sorts of duplicative code in different files (for instance, multiple different header and even source files that included the curses libraries and had to do different tests to see whether to include PDcurses, ncurses, or xcurses, and which had to test for which operating system you were compiling on and include different libraries depending on that, etc.), this similar code appearing in multiple different files when it came to what libraries were included was not a good programming practice and likely to lead to bugs (as this duplicative code in different files wasn't quite identical in them), so I moved all that code into common.h and had it included everywhere, and changed the #include lists for other files so that, for instance, now the .cpp files only have to include one header each, either externs.h for most of them or includes.h for game.cpp because it defines all those externs listed in externs.h.
But nickdumas fixed this in revision 817, apparently using the fix Jonathan S. Fox found. Anyway term.h seems to #define a lot of stuff. I don't have term.h on my system since it's a Windows system but I could move term.h's include back into common.h with the rest of the includes of external libraries if I put in the #undef for newline, and possibly other #undefs, since it seems term.h has a whole bunch of macros with short names, at least in one version of it I found via a Google search. Hmm, I wonder if nickdumas has an account on the forums here... probably, since he committed the exact same fix that Jonathan S. Fox posted in this thread.
Anyway what I did consolidating the #includes of external libraries into common.h will lead to less bugs in the long run because now there's no longer several different slightly different long sections with #ifdefs and #includes and whatnot in several different files, all of which were pretty similar but had differences. Now since it's all done in one place, if anything goes wrong we'll all know to fix it in that one place... in common.h. And if we need to make changes they only need to be done in that one place, rather than all those separate places where these #ifdefs and #includes were done before. I do apologize for that one minor mistake... it would've worked fine if it weren't for term.h having #defines in it that override stuff used in the logging code.
The term.h code I found is here:
http://www.opensource.apple.com/source/ncurses/ncurses-31/include/term.h. I think term.h is a bit of a mess, just like the curses.h from PDCurses... both of them #define too much stuff and some of the #defines are poorly named and likely to conflict with other code, in both cases... this is especially true for lowercase #defines that have short names. That kind of programming practice is highly discouraged nowadays, and in fact, often called "evil":
http://hbfs.wordpress.com/2009/11/17/defines-are-evil/ Of course these are the headers for the libraries included in the project, we can't exactly change the fact that they use evil programming practices. So yea, term.h defines "newline" as "CUR Strings[103]", and prior to this defines "CUR" as "cur_term->type.", so this leads the compiler to evaluate "newline" as "cur_term->type.CUR Strings[103]", based on the text of term.h. Instead of calling it "newline" they should've called it "_NEWLINE". They have some equally egregious #defines, such as defining "lines", "columns", "buttons", "bell", "tab", "tone", and "pulse", all of which are short lowercase words very likely to be used as names of variables or functions and lead to conflicts. So while I am responsible for this problem occurring, I think the shoddy practices for naming the #defines used in term.h are really what's to blame even more than me... they should've either used all-caps or preceded with underscores, preferably both. Even better would be if they had thought up a way to do it that didn't involve hundreds of #defines in the first place, and made their code object-oriented rather than exposing so many internals to the public namespace. OK, so maybe that last bit about object-oriented and avoiding #defines wasn't really possible since the header is also supposed to work in vanilla C as well, not just in C++... but my point about the names of the #defines still stands. When I look at that header and look at a MinGW header, the MinGW header is about a billion times better in terms of following recommended C/C++ programming practices and not defining stuff that would be likely to override variable or function names. PDCurses is guilty of the same thing in its header, but not to such an extent, as it mostly uses uppercase #defines.