| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
a static array. Christos Zoulas, Robert Elz, and Andreas Gustafsson
point out that is undefined behaviour by the C standard even if we
never access the pointer.
|
|
|
|
|
|
|
|
| |
While here, delete the section about predefined strings.
For manual pages, the concept is not important enough to be discussed
in such a prominent place, and some aspects of the text were also
misleading. Add a shorter version of the relevant parts to the
description of the \* escape sequence instead.
|
|
|
|
|
| |
by allowing the preprocessor to pass it through to the formatters.
Used for example by the groff_char(7) manual page.
|
|
|
|
| |
and provide a way to specify additional diff(1) options
|
|
|
|
| |
found by Thomas Klausner <wiz at NetBSD> via a compiler warning
|
|
|
|
|
| |
workaround in place for now for the benefit of older systems,
and other systems might contain similar problems.
|
| |
|
|
|
|
|
| |
latter is a NetBSD idiosyncrasy reported by wiz@. Also take into
account that NetBSD declares getsubopt(3) in the wrong header.
|
|
|
|
| |
used for example in the ditroff(7) manual of the groff package
|
| |
|
|
|
|
| |
escape sequences, used for example in the groff_char(7) manual page
|
|
|
|
|
| |
and some groff manual pages actually use them in .ft requests.
It's easy enough to handle these .ft requests in mandoc, too.
|
|
|
|
|
| |
Examples of manual pages (ab)using it
include groff(7), chem(1), groff_mom(7), and groff_hdtbl(7).
|
|
|
|
|
|
| |
don't respond with the lie: "No entry for chmod in the manual."
Instead, say "No entry for chmod in section 3 of the manual."
Came up after a question from kn@; OK kn@.
|
| |
|
| |
|
|
|
|
|
| |
in general, when introducing the *typographic* term "hyphen",
actually display a real hyphen in output modes supporting it.
|
|
|
|
|
|
| |
simplest and most important instructions together and at the
beginning. No text change.
Suggested by jmc@.
|
|
|
|
|
|
|
|
|
|
| |
In some cases, it meant "render as an ASCII character in output
modes that have a notion of codepoints" (e.g. UTF-8, HTML); in other
cases, "render in the text font in output modes that also provide
a special font for mathematical symbols" (e.g. PostScript, PDF).
Also explicitly annotate the escape sequences that use a special
font if available.
OK bentley@
|
|
|
|
|
|
|
|
| |
for hyphens and minus signs in manual pages.
Since there is consensus that a typographically perfect solution is
impossible, let's KISS - just write "-", don't bother with "\-", all
currently relevant manual page formatters can handle "-" reasonably.
OK jmc@ bentley@
|
|
|
|
|
| |
the sheer number of issues is amazing,
but they all look feasible
|
|
|
|
|
| |
string argument preceded a string argument beginning with "--".
Found by Leah Neukirchen <leah at vuxu dot org> with -Wpointer-compare.
|
|
|
|
|
|
| |
the parse point to the beginning of the new buffer or we risk out
of bounds accesses. Bug found by Leah Neukirchen <leah at vuxu dot
org> with valgrind on Void Linux.
|
|
|
|
|
| |
which occurred in situations like ".Fl a Cm --"; found by
Leah Neukirchen <leah at vuxu dot org> with valgrind on Void Linux.
|
|
|
|
|
|
| |
autodetect whether the compiler can use -W and -static,
clearer output from ./configure,
and adjust some configuration instructions
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Leah Neukirchen pointed out that mdoclint(1) used to warn about a
leading zero before the day number, so we know that both NetBSD and
Void Linux want the message. It does no harm on OpenBSD because
Mdocdate always does the right thing anyway.
jmc@ agrees that it makes sense in contexts not using Mdocdate.
|
| |
|
| |
|
|
|
|
|
| |
is already sufficient. John Gardner tells me that "CSS selectors
should only contain what's necessary to target their subjects".
|
|
|
|
| |
recommended by John Gardner <gardnerjohng at gmail dot com>
|
| |
|
|
|
|
| |
now that we no longer use variable style= attributes.
|
|
|
|
|
|
|
|
|
| |
Even though style=height is not particularly harmful for responsive
design except for very large arguments which don't really occur in
practice, it is not useful either: nobody should use .sp in manual
pages, in particular not with an argument. Even if somebody does,
ignoring the argument will likely make the output look better rather
than worse. Consequently, simplify by dropping a useless feature.
|
| |
|
|
|
|
| |
Since <div> uses HTML_NLAROUND, it is no longer needed.
|
| |
|
|
|
|
|
|
| |
author-specified column widths, which can harm responsive design and
provide no real benefit: HTML rendering engines usually do just
fine automatically selecting appropriate column widths.
|
|
|
|
|
| |
design. Use the existing @media-dependent indent instead.
This removes the last style= attribute from man(7) output.
|
| |
|
|
|
|
| |
harm responsive design; use @media-dependent defaults instead.
|
|
|
|
|
| |
doesn't actually harm responsive design, so keep it for now.
Bug reported in de.comp.os.unix.bsd via naddy@, thanks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a uniform indentation in CSS adapted to the viewport width and
ignore the value of the argument taken from mdoc(7). While
author-specified widths somewhat work as a micro-optimization in
terminal and typeset output, they are nothing but harmful in HTML
style= attributes because they break responsive design, whereas
using a reasonable default indent almost never results in ugly
output. Admittedly, the author-specified width might occasionally
look even better, but only slightly so, and only for some viewport
sizes.
Based on guidance provided by John Gardner.
|
|
|
|
|
| |
with -Tps or -Tpdf, do not squeeze the whole text beyond the right
margin. Bug reported by Will Backman during BSDCan.
|
|
|
|
|
|
| |
and use type=search rather than type=text for the input element
because it tends to better support autocompletion.
Both suggested by John Gardner <gardnerjohng at gmail dot com>.
|
|
|
|
| |
which are no longer used because we write fewer style= attributes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in HTML output. For terminal and typeset output, such arguments
kind of work to achieve presentational micro-optimization.
But for HTML, they only do harm.
Large increases usually look ugly. Large reductions are impossible
since the default is not large in the first place. Small tweaks in
either direction are not important; at least not important enough
to justify making responsive design impossible.
Triggered by John Gardner's suggestion to further reduce style=
attributes in the HTML code, in particular those containing hard-coded
lengths.
|