| Commit message (Collapse) | Author |
|---|
|
[originally from svn r10166]
|
|
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]
|
|
[originally from svn r7454]
|
|
[originally from svn r7453]
|
|
in the Info backend, with the defaults chosen to match what Emacs
recognises and renders prettily.
[originally from svn r7452]
|
|
[originally from svn r7451]
|
|
[originally from svn r7449]
|
|
commands, allowing the fixed words "Contents" and "Index" generated
in various output formats to be reconfigured into other languages.
[originally from svn r6724]
|
|
Halibut will output fragment names in all specified formats. (I forget now
precisely why I thought this was necessary, but it seems potentially useful.)
Also ensure that legal fragment names are generated even if none of the
characters from the original turn out to be legal (e.g., %k with an entirely
numeric keyword), and correct an untruth I inserted in the documentation of
this.
(This commit hits more than just the HTML backend as I've generalised an error
message, and fixed a fault in the info backend's error handling while there.)
[originally from svn r5457]
|
|
principles (it may be unnecessary). Perhaps we should do this for
(word)->private_data too.
[originally from svn r4412]
|
|
paragraph by another \[Kk], Bad Things would happen.
[originally from svn r4411]
|
|
an integer charset ID.
[originally from svn r4317]
|
|
(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]
|
|
[originally from svn r4131]
|
|
characters in order to wrap and align them properly. Therefore, they
should be using wcwidth(). So here are a couple of wrappers on
wcwidth(), one which filters out the Unicode characters not
representable in the target charset, and one which converts _from_ a
charset to Unicode before calling wcwidth(). bk_text and bk_info
should now align correctly even in the face of unsupported
characters and Japanese.
[originally from svn r4116]
|
|
checkin touches other files because a function in bk_text.c turned
out to be of more general use so I moved it out into ustring.c.)
[originally from svn r4111]
|
|
ustrfroma, utoa_dup and ufroma_dup now take a charset parameter, and
also have a variety of subtly distinct forms. Also, when a \cfg
directive is seen in the input file, the precise octet strings for
each parameter are kept in their original form as well as being
translated into Unicode, so that when they represent filenames they
can be used verbatim.
[originally from svn r4097]
|
|
representable in the output character set.
[originally from svn r4094]
|
|
an enormous amount of preprocessing and differ only in their final
output form, I've introduced a new type of layer called a
`pre-backend' (bk_paper.c is one). This takes all the information
passed to a normal backend and returns an arbitrary void *, which is
cached by the front end and passed on to any backend(s) which state
a desire for the output of that particular pre-backend. Thus, all
the page layout is done only once, and the PS and PDF backends
process the same data structures into two output files.
Note that these backends are _very_ unfinished; all sorts of vital
things such as section numbers, list markers, and title formatting
are missing, the paragraph justification doesn't quite work, and
advanced stuff like indexes and PDF interactive features haven't
even been started. But this basic framework generates valid output
files and is a good starting point, so I'm checking it in.
[originally from svn r4058]
|
|
items of the form `* stuff: Section 1.2.' are parsed by standalone
info as `Section 1.2' followed by a period, but are parsed by other
readers as `Section 1' followed by a period and then some spare
text. Therefore, I've changed strategy, and the index is now full of
*Note cross-references rather than menu items. On the plus side,
this means there are no longer any special characters which we can't
tolerate in an index entry; on the minus side, my shiny new
infrastructure for tracking the filepos of index entries is now
rendered pointless. I'll leave it in, though, since it may come in
handy again.
[originally from svn r4053]
|
|
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]
|
|
appear to be used to automatically construct /usr/info/dir.
[originally from svn r4049]
|
|
without going through the .texi source stage. A few things left to
do, notably documentation, but the basics all seem to be there.
[originally from svn r4047]
|
