halibut/index.c, branch master My halibut tree Add \s for 'strong' text, i.e. bold rather than italics. I've missed 2013-03-10T16:58:01+00:00 Simon Tatham anakin@pobox.com 2013-03-10T16:58:01+00:00 dcf080aa0e011de37a154e9e8a97dd7546a4a1b1 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] 
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]
Revamp of the Halibut error handling mechanism. 2012-08-29T18:13:11+00:00 Simon Tatham anakin@pobox.com 2012-08-29T18:13:11+00:00 1489dc15967970576d08f3f2b22c6e1c939bcbcf 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] 
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]
The Halibut manual contained at least one instance of two index 2004-06-13T14:57:25+00:00 Simon Tatham anakin@pobox.com 2004-06-13T14:57:25+00:00 a7963e261b59522cf57696b07058da760fb22e2e terms (intentionally) differing only in case, which were being silently folded into one by the case-insensitive index tag comparison. Halibut now warns in this situation (but then folds them anyway, which I think is better than silently generating an index containing many case-distinct forms of the same word - I imagine it's very easy to do that by mistake). The manual has been fixed to explicitly define distinct keywords (in the case I spotted and in five other cases picked up by the new warning!), and also documents this issue and how to work with it. [originally from svn r4279] 
terms (intentionally) differing only in case, which were being
silently folded into one by the case-insensitive index tag
comparison. Halibut now warns in this situation (but then folds them
anyway, which I think is better than silently generating an index
containing many case-distinct forms of the same word - I imagine
it's very easy to do that by mistake). The manual has been fixed to
explicitly define distinct keywords (in the case I spotted and in
five other cases picked up by the new warning!), and also documents
this issue and how to work with it.

[originally from svn r4279]
Switch the memory allocation macros from the Halibut ones 2004-06-12T20:31:03+00:00 Simon Tatham anakin@pobox.com 2004-06-12T20:31:03+00:00 a5d800d080a9eb557082042216636ac872eac7ec (mknew/mknewa/resize) to the PuTTY ones (snew/snewn/sresize). snewn and mknewa have their arguments opposite ways round; this may make the change initially painful but in the long term will free me of a nasty context switch every time I move between codebases. Also sresize takes an explicit type operand which is used to cast the return value from realloc, thus enforcing that it must be correct, and arranging that if anyone tries to compile Halibut with a C++ compiler there should be a lot less pain. [originally from svn r4276] 
(mknew/mknewa/resize) to the PuTTY ones (snew/snewn/sresize). snewn
and mknewa have their arguments opposite ways round; this may make
the change initially painful but in the long term will free me of a
nasty context switch every time I move between codebases. Also
sresize takes an explicit type operand which is used to cast the
return value from realloc, thus enforcing that it must be correct,
and arranging that if anyone tries to compile Halibut with a C++
compiler there should be a lot less pain.

[originally from svn r4276]
Support the locale-supplied character set where appropriate. It's 2004-04-22T17:27:05+00:00 Simon Tatham anakin@pobox.com 2004-04-22T17:27:05+00:00 55cf0a663723f6334b94de297776756b487c2cdf used for converting command-line -C directives into Unicode; it's used for outputting Unicode strings to stderr in error messages; and it's used as the default character set for input files (although I'd be inclined to recommend everyone use \cfg{input-charset} in all their source files to ensure their portability). [originally from svn r4114] 
used for converting command-line -C directives into Unicode; it's
used for outputting Unicode strings to stderr in error messages; and
it's used as the default character set for input files (although I'd
be inclined to recommend everyone use \cfg{input-charset} in all
their source files to ensure their portability).

[originally from svn r4114]
Info backend now takes care to avoid magic characters in node names 2004-04-10T08:59:19+00:00 Simon Tatham anakin@pobox.com 2004-04-10T08:59:19+00:00 cb859ab83ed22a1b0dc9fd017cb0d68e0037d750 and index terms (the Info format doesn't like them). In the course of this I've had to introduce some infrastructure for carrying a filepos forward from the definition of every RHS index term so that a particular backend can provide a usefully localised report of which index term had a problem. [originally from svn r4051] 
and index terms (the Info format doesn't like them). In the course
of this I've had to introduce some infrastructure for carrying a
filepos forward from the definition of every RHS index term so that
a particular backend can provide a usefully localised report of
which index term had a problem.

[originally from svn r4051]
I always meant to remove emphasis in the index by default. Now I do 2004-03-30T19:32:00+00:00 Simon Tatham anakin@pobox.com 2004-03-30T19:32:00+00:00 4265ea15b41a4f1ff299932ff55797c7b7641e7f so. It's restorable using \IM. [originally from svn r4000] 
so. It's restorable using \IM.

[originally from svn r4000]
Rename Buttress to Halibut. I _think_ I've caught everything in this pass. 2002-08-05T10:31:35+00:00 Simon Tatham anakin@pobox.com 2002-08-05T10:31:35+00:00 c478f3d9469c09773097eba89342c311ee70a319 [originally from svn r1800] 
[originally from svn r1800]
Indexing in the Help backend now seems to work! Woo! 2001-12-04T21:33:03+00:00 Simon Tatham anakin@pobox.com 2001-12-04T21:33:03+00:00 38181905971fab7106f1f4b90db8da26497158b9 [originally from svn r1450] 
[originally from svn r1450]
This update should bring the Windows Help back end up to 2001-12-04T21:12:40+00:00 Simon Tatham anakin@pobox.com 2001-12-04T21:12:40+00:00 5e3a21913b6a47e78d3e4edd4238d028b90827b7 near-complete functionality. All that's missing now is indexing and horizontal rules. [originally from svn r1449] 
near-complete functionality. All that's missing now is indexing and
horizontal rules.

[originally from svn r1449]