| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
'bob -s Buildscr.test' builds Halibut, runs it over inputs/test.but to
produce all the supported output formats, and delivers them all into
the output directory. Including Windows HTML Help, for which it has to
do a special run of the HTML back end with extra options and then get
a Windows box to run hhc (hence this having to be a Buildscr).
|
| |
|
|
|
|
|
| |
As far as I can tell from the source control history, Halibut has
_never_ actually printed an error message on failure to open one of
its input files! The error message has existed all along, but was
never actually invoked. Ahem.
|
| |
|
|
|
| |
There was a missing NULL check in the code that test-opens files in
both binary and text mode (for font-handling purposes).
|
| |
|
|
|
|
| |
Turns out we can get a null pointer passed through from the front end,
if the input file was erroneous in some way, so we should do fallback
processing if so (exactly what doesn't matter much) rather than crash.
|
| |
|
|
|
| |
I often symlink it down from the build directory, so let's be
sympathetic to other people who like to type './halibut'.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This causes sensible error reporting if distance codes 30 or 31 appear
in a compressed block.
(Not that Halibut actually _uses_ the Deflate decoder - it only uses
the encoder - but if I've got a copy of this code here then it should
be correct.)
[originally from svn r10280]
[r10278 == 3fd8014ea7235d0ec34e8f97a34f3ecf576e8239 in putty repository]
|
| |
|
|
|
|
|
|
| |
I forgot to add this in last week's versioning revamp, so that bob
builds work (constructing a version.h from the build script) but dev
builds straight from source control fail for lack of version.h.
[originally from svn r10277]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A long time ago, it seemed like a good idea to arrange that binaries
of Halibut would automatically cease to identify themselves as a
particular upstream version number if any changes were made to the
source code, so that if someone made a local tweak and distributed the
result then I wouldn't get blamed for the results. Since then I've
decided the whole idea is more trouble than it's worth, so I'm
retiring it completely.
[originally from svn r10254]
|
| |
|
|
|
|
|
|
|
|
| |
The \versionids in the docs are now added by the bob script; the one
in inputs/test.but has been replaced by fixed text (it didn't matter
what it contained anyway, of course, for test purposes), and the one
in misc/halibut.vim has simply been removed (it wasn't actually
expanded by svn anyway - it still had its old CVS value).
[originally from svn r10253]
|
| |
|
|
|
|
|
|
|
|
| |
The existing Halibut bob script defaults to building a completely
unversioned source tarball. I think building one with the version
format I'm now more or less standardising on (date + VCS id info) is a
more sensible default. So I'm retiring the SNAPSHOT setting, which I
never used anyway, and making the default work like that.
[originally from svn r10252]
|
| |
|
|
|
|
| |
Also from J. Lewis Muir.
[originally from svn r10213]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch due to J. Lewis Muir, who points out that the HTML backend's
current policy of _always_ disabling the TOC in single-file mode is
excessively harsh: in a long or formal enough document, you might
still want a TOC to make navigating around within the file easier,
even if it's not necessary to use it to get between multiple files.
So this change removes the unconditional prohibition against TOCs in
single-file documents, but they're still disabled by default, because
a single file counts as a leaf file and the existing default settings
disable TOCs in leaf files anyway. So if you do want a TOC in a single
file, you can reconfigure 'html-leaf-contains-contents' to true.
[originally from svn r10212]
|
| |
|
|
| |
[originally from svn r10166]
|
| |
|
|
| |
[originally from svn r9774]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this a couple of times in Halibut markup recently (in particular, it's
handy to have a typographical distinction between 'this term is
emphasised because it's new' and 'this term is emphasised because I
want you to pay attention to it'), so here's an implementation,
basically parallel to \e.
One slight oddity is that strong text in headings will not be
distinguished in some output formats, since they already use bolded
text for their headings.
[originally from svn r9772]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not quite sure why I ever thought it was a good idea to have a
central variadic error() function taking an integer error code
followed by some list of arguments that depend on that code. It now
seems obvious to me that it's a much more sensible idea to have a
separate function per error, so that we can check at compile time that
the arguments to each error call are of the right number and type! So
I've done that instead.
A side effect is that the errors are no longer formatted into a
fixed-size buffer before going to stderr, so I can remove all the
%.200s precautions in the format strings.
[originally from svn r9639]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
the standalone deflate utility modes, so you can redirect output to a
file and end up with correct data in that file.
[originally from svn r9552]
|
| |
|
|
|
|
|
|
|
| |
dynamic block in which the backward-distances Huffman table contains
no entries at all. (In this situation it's impossible to use the
distance table, and therefore the block must contain nothing but
Huffman-coded literals.)
[originally from svn r9550]
|
| |
|
|
|
|
| |
pass something that isn't necessarily an unsigned short.
[originally from svn r9493]
|
| |
|
|
|
|
|
|
|
|
| |
possible to specify an indent which is _overall_ negative, i.e.
intended to be off the left-hand side of the text file. There's no
nice way to handle this, but printing O(2^32) spaces in a while (n--)
loop is particularly bad. Fix the loop to read while (n-- > 0), so
that at least it doesn't get _that_ badly confused.
[originally from svn r9491]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
on an uncompressed block.
[originally from svn r9482]
[r6972 == 37af901cfe63ed062306e3835751e9b8e089e252 in misc repository]
|
| |
|
|
| |
[originally from svn r9478]
|
| |
|
|
| |
[originally from svn r9476]
|
| |
|
|
|
|
|
| |
block headers. (Ubuntu 12.04's gcc spotted that nlen was unused, which
it shouldn't have been.)
[originally from svn r9475]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
converting a number! Oops. Now you can do things like
\cfg{text-list-indent}{-2}
\cfg{text-listitem-indent}{2}
to get your bullets placed in the left margin rather than indenting
the paragraphs of your list.
[originally from svn r9474]
|
| |
|
|
|
|
|
| |
tok_eop, to prevent Halibut tight-looping when a definition is the
last thing in a file.
[originally from svn r9419]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
[originally from svn r9259]
|
| |
|
|
|
|
|
|
|
| |
work on Windows, because input files are never opened in binary
mode. Introduce a small piece of compensatory mechanism, which opens
files initially in binary mode and then reopens them as text if
they're determined not to match any binary file type. I hope.
[originally from svn r8889]
|
| |
|
|
|
|
| |
look less as if they're the _only_ config options.
[originally from svn r8842]
|
| |
|
|
| |
[originally from svn r8743]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"-" as a special file name meaning standard output. I've restricted
it to just those output formats which can predictably output only
one file, just for the sake of not having to faff too much with the
others.
Probably what I should have done for all of this would have been to
write a set of wrappers around fopen, fclose and everything in
between, and use them everywhere. Those wrappers would uniformly
detect "-" and convert it into stdin or stdout as appropriate, would
avoid fclosing those files for real when told to close them, and
would also be able to handle reading a little bit of data from the
start of a file and then pushing it all back even if the file were
not seekable (which would allow input.c to lose the ugly special
case whereby it can't currently read font files from standard
input).
[originally from svn r8729]
|
| |
|
|
|
|
| |
the special filename '-'.
[originally from svn r8728]
|
| |
|
|
|
|
|
|
| |
apparently this is preferred (it's what pod2man uses); cf Debian #496063,
#159872.
[originally from svn r8641]
[r8309 == 73e8c7d1b4ac77ec1b5acc700cb3af277a150bcf]
|
| |
|
|
|
|
|
| |
(via Colin in Debian bug#496063).
[originally from svn r8640]
[r8321 == 5e7a3a5b1bbaccb7ce7d61bb9bc4654924135dfb]
|
| |
|
|
|
|
|
| |
the list.
[originally from svn r8498]
[this svn revision also touched charset,filter,timber]
|
| |
|
|
|
|
|
| |
\cfg{paper-contents-margin}. Also correct the spelling of the
former.
[originally from svn r8424]
|
| |
|
|
|
|
| |
Watson.)
[originally from svn r8422]
|
| |
|
|
|
|
| |
Fix it.
[originally from svn r8421]
|
| |
|
|
|
|
|
|
|
| |
unsigned char. On platforms were char is signed, passing plain char won't
cut it. Make sure we case chars to unsigned char before passing them to
tolower().
[originally from svn r8404]
[this svn revision also touched charset,filter,timber]
|
| |
|
|
|
|
| |
[originally from svn r8322]
[r8309 == 73e8c7d1b4ac77ec1b5acc700cb3af277a150bcf]
[r8321 == 5e7a3a5b1bbaccb7ce7d61bb9bc4654924135dfb]
|
| |
|
|
|
|
|
|
|
|
| |
contexts get output usefully in the face of UTF-8 *roff implementations.
Works on Debian-derived distributions (and hence along with r8309 should fix
#496063), but I'm slightly worried about portability as I've used a named
character "\(aq" which doesn't appear in the "classic" reference CS TR #54.
[originally from svn r8321]
[r8309 == 73e8c7d1b4ac77ec1b5acc700cb3af277a150bcf]
|
| |
|
|
| |
[originally from svn r8320]
|
| |
|
|
|
|
|
| |
to try to put them into an Info node name, so as to avoid the error
message when it fails.
[originally from svn r8313]
|