| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
such that even pages without any .SH macros get it
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
| |
sufficient for pages using po4a(1)
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
| |
record that detail in struct tbl_opts, such that term_tbl() can do
correct column calculations and doesn't prematurely break lines.
Fixes the tbl/layout/empty regression test that got broken when
line breaking in text block cells was implemented.
|
| |
|
|
|
|
|
| |
We provide users with tools. We don't attempt to prevent them from
using them in stupid ways: depending on the context, not every
stupid-looking use is necessarily actually stupid, and not every
stupidity can be automatically detected anyway, so don't even try.
|
| | |
|
| |
|
|
|
|
| |
With the current code structure, they would appear at the wrong
place in the syntax tree, so it is better to not insert them
into the tree at all and issue an UNSUPP message instead.
|
| | |
|
| |
|
|
|
|
| |
1. It does not reduce explicit "||" in the layout to "|".
2. It does not cause three horizontal lines at the end of a table,
even if the table ends with an explicit "_" data line.
|
| |
|
|
|
|
|
| |
given column, that column contains no literal or numeric cell of
larger width, and all text block cells in that column can be line
wrapped to fit into that minimum width, groff does not increase
that column width beyond the specified minimum: so do the same.
|
| |
|
|
| |
used for example by curs_getch(3) and GLwDrawingArea(3)
|
| | |
|
| |
|
|
|
| |
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@.
|
| | |
|
| | |
|
| |
|
|
| |
This brings us down to one false positive for about every 18 pages.
|
| | |
|
| |
|
|
| |
inspired by mdoclint(1), and jmc@ considers it useful
|
| | |
|
| |
|
|
|
| |
or this may crash with use-after-free in makewhatis(8);
reported by jmc@, thanks!
|
| |
|
|
|
| |
Improve width calculation of text blocks.
Reduces the groff/mandoc diff in Base+Xenocara by about 800 lines.
|
| |
|
|
|
| |
a pointer to the end of the parsed data, making it easier to
parse subsequent bytes
|
| | |
|
| | |
|
| |
|
|
|
| |
between the sentences. Thomas Klausner says he has seen some
of these, and i don't see any false positives.
|
| |
|
|
|
|
|
|
|
| |
Also catch cases where the new sentence starts with a one-letter word
and the input line is broken right after that word.
Suggested by Thomas Klausner <wiz @ NetBSD>.
It's merely a three-bit diff, changing one byte from 0x34 to 0x33,
so what can possibly go wrong...
|
| |
|
|
|
|
|
|
|
|
| |
second step: make the per-column byte pointer persistent across
term_flushln() calls, such that a subsequent call can continue at
the point where the previous call left. If more than one column
is in use, return from term_flushln() when the column is full,
rather than breaking the output line.
No functional change, because nothing sets up multiple columns yet.
|
| |
|
|
|
|
| |
first step: split column data out of the terminal state struct into
a new column state struct and use an array of such column state
structs. No functional change.
|
| |
|
|
|
|
| |
and after that, previously written output gets overwritten, but
overwriting with blanks does *not* erase previously written content.
Yes, manual pages exist that are crazy enough to rely on that...
|
| |
|
|
|
|
|
|
|
|
| |
Renaming a user-defined macro is very simple: just copy
the definition to the new name and delete the old name.
Renaming high-level macros is a bit tricky: use a dedicated
key-value-table, with non-standard names as keys and standard
names as values. When a macro is found that is not user-defined,
look it up in the "renamed" table and translate it back to the
standard name before passing it on to the high-level parsers.
|
