| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
* Do not discard data that lacks a matching layout cell but remains
within the number of columns of the table as a whole.
* Do not insert dummy data rows for any layout row starting with a
horizontal line, but only for layout rows that would discard all
the data on a matching non-empty data row.
* Print horizontal lines specified in the layout even if there is
no matching data cell.
* Improve the logic for extending vertical lines to adjacent rows,
for choosing cross marks versus line segments, and some related details.
|
| |
|
|
|
|
| |
used for example by zoem(1)
|
|
|
|
|
|
| |
This clearly works when .po is called on the top level, but might
not be sophisticated enough if people call .po inside indentation-changing
contexts, but i haven't seen that in manual pages (yet :).
|
|
|
|
| |
abused by mail/nmh; groff_char(7) confirms that this really exists
|
| |
|
|
|
|
| |
in horizontal orientation in the terminal formatter
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Manuals autogenerated from reStructuredText are reckless enough
to peek at this non-portable, implementation-dependent, highly
groff-specific internal register - for no good reason, because the
man(7) language natively provides in a much simpler way what they
are trying to emulate here with much fragility.
A full implementation would be very hard because it would require
access to output-device-specific formatting data at the roff(7)
preprocessor stage, which mandoc doesn't support at all.
So hardcode a few magic numbers as reStructuredText expects them
for terminal output. For other output modes (like HTML), code using
this register is utterly broken anyway.
|
| |
|
| |
|
|
|
|
|
| |
inside individual table cells that contain text blocks.
This cures overlong lines in various Xenocara manuals.
|
|
|
|
|
| |
and operating system dependent messages about missing or unexpected
Mdocdate; inspired by mdoclint(1).
|
|
|
|
|
| |
and operating system dependent messages about missing or unexpected
Mdocdate; inspired by mdoclint(1).
|
|
|
|
|
|
|
| |
In practice, that message only matters inside .Bf, and even there, it
can occasionally be a false positive. In all other cases, it usually
is a false positive, so it is better to drop it outright.
Suggested by jmc@.
|
| |
|
| |
|
|
|
|
| |
inspired by mdoclint(1), and jmc@ considers it useful
|
|
|
|
|
| |
Improve width calculation of text blocks.
Reduces the groff/mandoc diff in Base+Xenocara by about 800 lines.
|
| |
|
|
|
|
| |
strange groff edge case behaviour found in multimedia/mjpegtools
|
|
|
|
| |
triggered by multimedia/mkvtoolnix mkvmerge(1) using \(S2
|
|
|
|
| |
Good enough to cope with the average DocBook insanity.
|
|
|
|
| |
not a WARNING because they don't endanger portability
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
and of called macros.
This bug affects almost all macros, and fixing it simplifies the
code. It is amazing that the bogus ARGS_QWORD feature got implemented
in the first place, and then carrier along for more than eight years
without anybody ever noticing that it was pointless.
Reported by Leah Neukirchen <leah at vuxu dot org>, found on Void Linux.
|
|
|
|
| |
Needed by about four dozen ports (thanks to naddy@ for the research).
|
|
|
|
|
|
| |
This is the first feature made possible by the parser reorganization.
Improves the formatting of the SYNOPSIS in many Xenocara GL manuals.
Also important for ports, as reported by many, including naddy@.
|
|
|
|
| |
now that this actually saves code: -70 LOC.
|
|
|
|
|
| |
modules to the new roff(7) modules. As a side effect,
mdoc(7) now handles .ft, too. Of course, do not use that.
|
|
|
|
|
| |
Generate the first node on the roff level: .br
Fix some column numbers in diagnostic messages while here.
|
|
|
|
|
|
|
| |
widths of the remaining columns is already wider than the line
length, underflowing size_t and dying from ENOMEM is the wrong plan.
Instead, simply refrain from expanding anything in such a situation,
avoiding a crash that tb@ found with afl.
|
|
|
|
| |
and warn about it; mdoclint(1) does so, and it makes sense.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with respect to what constitutes a valid autolink, and if a compiler
deems an autolink invalid, the input turns into an unintended and
potentially harmful raw HTML tag. So, never write autolinks.
Instead of <link>, write [link](link).
Instead of <addr>, write [addr](mailto:addr).
Issue pointed out by bentley@, who also agrees with the general
direction of the change.
|
|
|
|
|
|
|
| |
Now that markdown output is tested for almost everything, test all
input files in -T markdown output mode by default and only mark
those files with SKIP_MARKDOWN that are not to be tested.
Much easier to read, and almost minus 40 lines of Makefile code.
|
|
|
|
|
|
| |
input files in -T markdown output mode by default and only mark
those files with SKIP_MARKDOWN that are not to be tested.
Much easier to read, and almost minus 40 lines of Makefile code.
|
|
|
|
| |
and markdown markup do not work inside code spans.
|
| |
|
| |
|
| |
|
|
|
|
| |
of a user-defined macro; issue found by tb@ with afl(1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
limit, usually due to infinite recursion, discard whatever remains
in all those open stack levels. Otherwise, insane constructions
like the following could generate macros of enormous size, causing
mandoc(1) to die from memory exhaustion:
.de m \" original macro definition
.m \" recursion to blow up the stack
.de m \" definition to be run during the call of .m marked (*)
very long plain text (some kilobytes)
.m \" expand the above a thousand times while unwinding the stack
.. \" end of the original definition
.m \" (*) recursively generate a ridiculously large macro
.. \" end of recursively generated definition
.m \" execute the giant macro, exhausting memory
Very creative abuse found by tb@ with afl(1).
|
|
|
|
| |
such that they don't look like output line breaks.
|
| |
|
| |
|
| |
|
|
|
|
| |
No ‌ in the middle of **, please.
|