summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Denote multiple arguments with 'arg ...' not 'args'.Ingo Schwarze2023-04-281-4/+2
| | | | From kn@, OK jmc@.
* Finally expand and delete the macro SCALE_VS_INIT().Ingo Schwarze2022-09-112-12/+8
| | | | | | It's nothing but obfuscation and only used at three places in a single file. Removing it also makes the code three lines shorter. The ugliness was already pointed out six years ago by mmcc@.
* Replace ugly .sp requests with normal .Pp macros.Ingo Schwarze2022-08-281-3/+3
| | | | After tbl_term.c 1.79, such contortions are no longer needed.
* revert previous, which was committed by accidentIngo Schwarze2022-08-281-1/+3
|
* Adjust desired output after tbl_term.c rev. 1.79 (stop skippingIngo Schwarze2022-08-281-4/+0
| | | | | | | | | vertical space after boxed tables). I'm committing this separately because trying to regenerate the desired output with groff-current reveals an unrelated, recent regression in groff. So i fixed the groff output by hand before committing it, to get rid of the effect of the roff regression.
* Vertical spacing changes around tables in man_term.c rev. 1.241Ingo Schwarze2022-08-2844-842/+56
| | | | | and tbl_term.c rev. 1.79 cause quite a bit of churn, unfortunately. This commit cleans up most of it.
* Stop skipping vertical space after boxed tables.Ingo Schwarze2022-08-281-6/+2
| | | | | | | | | Skipping such space used to be a bug in GNU tbl(1), and a kludge was added to mandoc to produce identical output. The bug was fixed in groff commit 8818c07c Jul 30 2022 gbranden@ https://savannah.gnu.org/bugs/index.php?49390 Consequently, now is the time to get rid of the kludge.
* Stop unconditionally emitting vertical space before .TS (table start).Ingo Schwarze2022-08-281-1/+1
| | | | | | | | | | | | | | | Same change as in groff commit 7ec36dc9 Jul 30 2022 gbranden@ For more details, see https://savannah.gnu.org/bugs/index.php?62841 This change makes sense because: * It improves the formatting of more pages than it degrades. * Existing manual pages are wildly inconsistent in which behaviour they expect: apparently few manual page authors understood the old rules. * It simplifies the rules of how .TS behaves in man(7) and makes them more similar to how it behaves in mdoc(7). * It improves flexibility, making it possible for a table to immediately follow preceding text without a blank line, which some existing pages want to use, for example XCreateWindow(3).
* Up to version 1.22.4, groff_mdoc(7) only considered the first wordIngo Schwarze2022-08-195-36/+33
| | | | | | | | | | | | when comparing section headers. For example, ".Sh SEE ELSEWHERE" and ".Sh SEE Em ALSO" were considered instances of a SEE ALSO section. In groff-current, exact matches with no sub-macros are required. Adjust mandoc behaviour. While here, also fix a very minor mandoc bug, even though no detrimental effect of the bug on formatting is known. While using sub-macros in the .Sh HEAD is bad style, the parsers accept it, so setting the section attribute on the HEAD needs to act recursively.
* Adjust desired output after the bugfix man.c rev. 1.189.Ingo Schwarze2022-08-161-1/+1
| | | | The new version of the output file was generated with groff-current.
* Restore the traditional behaviour of the man(7) single-fontIngo Schwarze2022-08-161-10/+9
| | | | | | | | | | | | | | | | | | | macros .B, .I, .SM, and .SB that the next-line scope extends to the end of the next logical input line and is not extended if that line ends with a \c (no-space) escape sequence. While improving a loosely related feature in the man(7) .TP macro, a regression entered the groff codebase in groff commit 3549fd9f (28-Apr-2017) caused by the usual sloppiness of Bjarni Ingi Gislason. Since that time, groff wrongly had \c extend next-line scope to a second line for these macros. In man.c rev. 1.127 (25-Aug-2018) i synched mandoc behaviour with groff in this respect, unfortunately failing to notice the recent regression in groff. The groff regression was finally fixed by gbranden@ in commit 09c028f3 (07-Jun-2022). With the present commit, mandoc is back in sync with both GNU and Heirloom roff regarding the interaction of single-font macros with \c.
* New tests of tabs in fill mode, in particularIngo Schwarze2022-08-163-2/+140
| | | | when multiple input or output lines are involved.
* Adjust the desired output after the improvements in term.c rev. 1.290.Ingo Schwarze2022-08-161-1/+1
| | | | | | The new version of this file was generated with groff-current. Heirloom nroff produces exactly the same output for the content of the DESCRIPTION.
* When starting a new input line, even when continuing the same outputIngo Schwarze2022-08-165-11/+49
| | | | | | line, use the current output position as the reference position for tabs on that input line. This brings mandoc in line with the behaviour of GNU, Heirloom, and Plan 9 roff.
* Even though the constant ASCII_ESC is only used in the roff pre-parser roff.c,Ingo Schwarze2022-08-162-9/+8
| | | | | move it to the top level include file mandoc.h to reduce the risk of causing clashes when introducing new ASCII_* constants in the future.
* Some more tests of no-fill mode similar to mdoc/Bd/blank.inIngo Schwarze2022-08-152-10/+29
| | | | after vertical spacing was improved in man_term.c rev. 1.239.
* Simplify handling of no-fill mode in man(7) by inspecting NODE_NOFILLIngo Schwarze2022-08-151-24/+20
| | | | | | | | | | | | | at the beginning of the node handler, in the same way as it is done in the mdoc(7) node handler. As a side effect, this also fixes a bug: if an input line contained nothing but an escape sequence producing no output whatsoever (for example, \fR), the old code incorrectly emitted a blank line anyway, whereas the new code only emits such a blank link if the input line actually produces output (even invisible zero-width output). To make the distinction, the ASCII_NBRZW -> lastcol -> term_newln() mechanism established in term.c rev. 1.289 is used.
* Distinguish between escape sequences that produce no outputIngo Schwarze2022-08-157-17/+52
| | | | | | | | | | | | | | | | | whatsoever (for example \fR) and escape sequences that produce invisible zero-width output (for example \&). No, i'm not joking, groff does make that distinction, and it has consequences in some situations, for example for vertical spacing in no-fill mode. Heirloom and Plan 9 behaviour is subtly different, but in case of doubt, we want to follow groff. While this fixes the behaviour for the majority of escape sequences, in particular for those most likely to occur in practice, it is not perfect yet because some of the more exotic ESCAPE_IGNORE sequences are actually of the "no output whatsoever" type but treated as "invisible zero-width" for now. With the new ASCII_NBRZW mechanism in place, switching them over one by one when the need arises will no longer be very difficult.
* In GNU, Heirloom, and Plan 9 roff, tab positions apply to *input* lines,Ingo Schwarze2022-08-153-7/+12
| | | | | | | | | | | | | not to *output* lines. In particular, if an input line gets broken in fill mode and a tab occurs in the second output line, it advances to a position of at least (width of the first output line) + (width of a space character even though this is never printed) + (width of the part of the second output line that precedes the tab). Implement the same logic in mandoc. Again, do not use tabs in filled text: they have surprising effects, including this one.
* In GNU, Heirloom, and Plan 9 roff, literal tab characters areIngo Schwarze2022-08-151-19/+15
| | | | | | | | | | | | | non-breakable in exactly the same way as "\ ". That is, the preceding word, the tab character, and the following word are always kept together on the same output line. If filling is enabled and an output line break is required before the end of the following word, the break occurs before the beginning of the preceding word. Make mandoc behave in the same way. Of course, using literal tab characters in filled text remains a bad idea, and the "WARNING: tab in filled text" remains unchanged.
* two ideas from RGBDSIngo Schwarze2022-08-091-0/+8
|
* prevent breakable hyphens in segment identifiersIngo Schwarze2022-08-091-2/+5
| | | | | from being turned into underscores; bug reported by <Eldred dot fr> Habert
* For clarity and consistency, refer to ".Bx 4.0" rather than ".Bx 4".Ingo Schwarze2022-08-041-1/+3
| | | | Also, mention /usr/ucb/man because /usr/bin/man did not provide -f in 4.0BSD.
* If the body of a man(7) .MT or .UR block is empty, do not emit a warning.Ingo Schwarze2022-08-024-9/+1
| | | | | | | | | | | | | | | Leaving the body empty is legitimate in this case if the author only wants to display a mail address or URI without providing a link text. Output modules already handle this correctly: terminal output shows just the URI without an accompanying text, HTML output uses the URI for *both* the href= attribute and as the content of the <a> element. The documentation was also wrong and claimed that an .MT or .UR block with an empty body would produce no output. As explained above, this isn't true. Bogus warning reported by Alejandro Colomar <alx dot manpages at gmail dot com>.
* Delete OpenBSD-only rules from the regress/roff/de MakefileIngo Schwarze2022-08-021-38/+0
| | | | | after they were changed in OpenBSD. Tracking these rules here would be useless.
* For accessibility, label the last two widgets in the search form.Ingo Schwarze2022-07-061-4/+6
| | | | Patch from Anna Vyalkova <cyber at sysrq dot in>, significantly tweaked by me.
* https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/ says:Ingo Schwarze2022-07-063-7/+7
| | | | | | | "Start names with a capital letter; it helps some screen readers speak them with appropriate inflection." Anna Vyalkova already did that correctly when sending patches, but i ruined it when committing, so fix it now.
* improve the description of header.html and footer.htmlIngo Schwarze2022-07-061-4/+6
|
* assign the ARIA role "doc-subtitle" to the .Nd element;Ingo Schwarze2022-07-061-1/+1
| | | | discussed with Anna Vyalkova <cyber at sysrq dot in>
* While the HTML standard allows multiple <h1> elements in the sameIngo Schwarze2022-07-0614-41/+41
| | | | | | | | | | | | document, <h1> is intended for top level headers, and most of the sections in a manual page can hardly be considered top-level. It is more usual to use <h1> only for the main title of the document of for the site name. Consequently, move .Sh/.SH from <h1> to <h2> and .Ss/.SS from <h2> to <h3>, freeing <h1> for use by header.html in man.cgi(8). Discussed with Anna Vyalkova <cyber at sysrq dot in>.
* Finally get rid of the archaic <table> markup for header and footer linesIngo Schwarze2022-07-054-41/+49
| | | | | | | | | | | and use flexbox CSS instead. Improve accessibility by adding role and aria-label attributes to these header and footer lines. Using ideas from both Anna Vyalkova <cyber at sysrq dot in> and myself. As a welcome side effect, this also resolves the long-standing issue that the rendering was always 65em wide, requiring horizontal scrolling when the window was narrower. Now, rendering nicely adapts to browser windows of arbitrary narrowness.
* Somehow, the content of header.html ended upIngo Schwarze2022-07-051-30/+42
| | | | | | before and outside the <header> element. Fix this by moving it into the <header> element where it belongs. While here, also wrap footer.html in a <footer> element.
* Improve accessibility of man.cgi(8) in various respects,Ingo Schwarze2022-07-041-15/+32
| | | | | | | in particular adding <header>, <main>, and <nav> elements and role and aria-label attributes in several places. Patch from Anna Vyalkova <cyber at sysrq dot in>, minimally tweaked by me.
* Put the HTML comment containing the Copyright header (if any)Ingo Schwarze2022-07-042-4/+4
| | | | | | | between the <head> and the <body> rather than before the <head> because the <meta charset="utf-8"/> element ought to be within the first 1024 bytes of the HTML code. Issue found with validator.w3.org.
* spelling; patch from jsg@Ingo Schwarze2022-07-031-1/+1
|
* Instead of the custom <div class="manual-text">, use the standardIngo Schwarze2022-07-035-6/+7
| | | | | | | | | | HTML <main> element. The benefit is that it has the ARIA landmark role "main" by default. To ease the transition for people using their own CSS file instead of mandoc.css, retain the custom class for now. I had this idea in a discussion with Anna Vyalkova <cyber at sysrq dot in>. Patch from Anna, slightly tweaked by me.
* In groff commit 78e66624 on May 7 20:15:33 2021 +1000,Ingo Schwarze2022-06-262-2/+2
| | | | | | G. Branden Robinson changed the -T ascii rendering of \(sd, the "second" symbol, U+2033 DOUBLE PRIME, from '' to ". Follow suit in mandoc.
* additional info regarding the .nf <br/> issueIngo Schwarze2022-06-261-1/+3
|
* If an .Xr macro contains a section argument, write an aria-label attributeIngo Schwarze2022-06-252-11/+21
| | | | | | | | such that users of screen readers aren't forced to listen to lengthy and distracting readings like "mdoc, left parenthesis, 7, right parenthesis". Based on a patch from Anna Vyalkova <cyber at sysrq dot in>, significantly tweaked by me.
* Improve accessibility of -T html -O toc output by using the <nav> elementIngo Schwarze2022-06-244-2/+12
| | | | | | | | | | | | | in the DPUB-ARIA doc-toc role. Patch from Anna Vyalkova <cyber at sysrq dot in> slightly tweaked by me. This is hopefully the start of a collaboration to improve accessibility of Unix manual pages using the WAI-ARIA, HTML-ARIA, and DPUB-ARIA standards. Progress appears to be possible without changing *anything* with respect to the way manual pages are written. Instead, it seems sufficient to properly translate semantic cues already implied by existing mdoc(7) markup into the appropriate HTML elements and ARIA attributes. Overall, the total length of HTML output is likely to increase slightly, but not much.
* Delete the statement that the default stylesheet only used CSS1Ingo Schwarze2022-06-221-1/+0
| | | | | | | | | | | | | | | | because that has no longer been true for some time now. I would certainly like to adhere to a coherent standard and state which one that is. Unfortunately, the W3C deliberately smashed the CSS standard into pieces such that a coherent standard no longer exists and such that statements about standard conformance have become next to meaningless. Consequently, i now remain reluctantly silent regarding CSS standard(s) conformance. Going back to CSS2.1, published in 2011, which was the last CSS standard in the proper sense of the word, is not an option because it has gaping holes in functionality and is no longer adequate for use on today's WWW.
* #include <stddef.h>, needed for NULL; bug reported by op@Ingo Schwarze2022-06-211-0/+2
|
* When looking for the next block to tag, we aren't interested in childrenIngo Schwarze2022-06-081-1/+2
| | | | | of the current block but really want the next block instead. This fixes a segfault reported by Evan Silberman <evan at jklol dot net> on bugs@.
* Surprisingly, every escape sequence can also be used as an argumentIngo Schwarze2022-06-0829-52/+1053
| | | | | | | delimiter for an outer escape sequence, in which case the delimiting escape sequence retains its syntax but usually ignores its argument and loses its inherent effect. Add rudimentary support for this syntax quirk in order to improve parsing compatibility with groff.
* Split the excessively generic diagnostic message "invalid escape sequence"Ingo Schwarze2022-06-0710-21/+44
| | | | | into the more specific messages "invalid escape argument delimiter" and "invalid escape sequence argument".
* Purge duplicate error reporting from the .tr request parser:Ingo Schwarze2022-06-071-11/+2
| | | | | the error was already reported earlier when roff_expand() called roff_escape().
* To better match groff parsing, reject digits and some mathematicalIngo Schwarze2022-06-061-7/+9
| | | | | | | | | | | | | | | | | | operators as argument delimiters for some escape sequences that take numerical arguments, in the same way as it had already been done for \h. Argument delimiter parsing for escape sequences taking numerical arguments is not perfect yet. In particular, when a character representing a scaling unit is abused as the argument delimiter, parsing for that character becomes context-dependent, and it is no longer possible to find the end of the escape sequence without calling the full numerical expression parser, which i refrain from attempting in this commit. For now, continuing to misparse insane constructions like \Bc1c+1cc (which is valid in groff and resolves to "1" because 1c+1c = two centimeters is a valid numerical expression and 'c' is also a valid delimiter) is a small price to pay for keeping complexity at bay and for not losing focus in the ongoing series of refinements.
* adjust two desired error messages after roff_escape.c rev. 1.11Ingo Schwarze2022-06-061-2/+2
| | | | improved diagnostics for the \C escape sequence
* Allow arbitrary argument delimiters for \C, like groff does.Ingo Schwarze2022-06-061-4/+5
| | | | | | | | | The restriction of only allowing ' as the delimiter was introduced by kristaps@ on 2011/04/09 when he first supported \C. For most other escape sequences, similar restrictions were relaxed later on, but for the rarely used \C, it was apparently forgotten. While here, reject empty character names: they are never valid.
* add and update a few entriesIngo Schwarze2022-06-061-0/+11
|
generated by cgit (git 2.34.1) at 2024-11-10 06:50:35 +0000