Also updates libcharset to the latest revision, which updates _its_ .gitignore (and pulls in other previous fixes too).
This commit updates the libcharset submodule to incorporate the autotools-ification that I just pushed to that subproject, and builds on it by replacing Halibut's own makefile system similarly with an autotools setup. The new Makefile.am incorporates both of the old Makefile and doc/Makefile, so a single run of 'make' should now build Halibut itself and all the formats of its own documentation, which also means that the automake-generated 'make install' target can do the right thing in terms of putting an appropriate subset of those documentation formats in the assorted installation directories. The old Makefiles are gone, as is release.sh (which is now obsolete because autotools's 'make dist' doesn't do anything obviously wrong). The bob build script is comprehensively rewritten, but should still work - even the clang-based Windows build can use the autotools-generated makefile system, provided I do the libcharset build with a manual override of bin_PROGRAMS to prevent it trying to build the libcharset supporting utilities (which are not completely Windows-portable).
Most of the changes since Halibut's last update have been to libcharset's supporting utility collection or have added extra API functions that Halibut doesn't need, but one actually relevant thing that this change brings in is the expanded set of easy-to-type character set encoding names, so that for example you can now say -Ctext-charset:mac-roman where you would previously have had to put a space in the middle of 'Mac Roman' and faff about with quoting on the shell command line.
specify characters to 'confuse' is to just put them on the command line in the system multibyte encoding! In a UTF-8 terminal environment this may very well be the easiest thing. [originally from svn r9584] [this svn revision also touched charset,filter,timber]
Unicode values (typically two of them), and it finds cases in which the provided characters are all encoded as the same thing in different charsets and prints those charsets. So if you encounter, for example, some piece of text which has U+0153 LATIN SMALL LIGATURE OE where you might have expected U+00A3 POUND SIGN, simply run 'confuse 153 a3' and it'll tell you which character sets the sender and receiver of the text might have got confused between. [originally from svn r9581] [this svn revision also touched charset,filter,timber]
[originally from svn r9580] [this svn revision also touched charset,filter,timber]
and a long int. Spotted by Ubuntu 12.04's gcc, and probably would have caused trouble on 64-bit machines. [originally from svn r9489] [this svn revision also touched charset,filter,timber]
I had wrongly believed my TYPECHECK macro double-evaluated one of its arguments and hence would cause side effects to happen twice. But in fact I've just realised that although it double-_expands_ the argument, it doesn't double-_evaluate_ it: the two expansions occur in mutually exclusive branches of a ?:, and hence cannot both be executed. So I've removed the comment that says my macro is rubbish. My macro is in fact great :-) [originally from svn r9328] [this svn revision also touched charset,filter,timber]
[originally from svn r9327] [r9326 == c72d4b413f024e3c50645caceaddbb65401fb06a in putty repository] [this svn revision also touched charset,filter,timber]