summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 1. Do not put ASCII_HYPH (0x1c) into the tag file.Ingo Schwarze2023-11-244-25/+47
| | | | | | | | | | That happened when tagging a string containing '-' on an input text line, most commonly in man(7) .TP next line scope. 2. Do not let "\-" end the tag. In both cases, translate ASCII_HYPH and "\-" to plain '-' for output. For example, this improves handling of unbound.conf(5). These two bugs were found thanks to a posting by weerd@.
* already an old idea: abbreviate pathnames for -MIngo Schwarze2023-11-241-1/+5
|
* reduce the man(7) global indentation from 7n to 5n, see man_term.c rev. 1.244Ingo Schwarze2023-11-1343-534/+582
|
* reduce the man(7) global indentation from 7n to 5n, see man_term.c rev. 1.244Ingo Schwarze2023-11-13187-2456/+2453
|
* forgotten output file found in my treeIngo Schwarze2023-11-131-0/+4
|
* Reduce the man(7) default global indentation from 7n, which was an oddityIngo Schwarze2023-11-135-25/+10
| | | | | | in groff-1.01 to groff-1.22.4, to 5n for compatibility with Version 7 AT&T UNIX, 4.3BSD-Reno, groff-1.23.0, and all versions of mdoc(7). OK jmc@ millert@
* new: warn about \\ and \. in interpretation modeIngo Schwarze2023-11-131-0/+3
|
* Implement the man(7) .MR macro, a 2023 GNU extension.Ingo Schwarze2023-10-2413-16/+215
| | | | | | | | | | | The syntax and semantics is almost identical to mdoc(7) .Xr. This will be needed for reading the groff manual pages once our port will be updated to 1.23, and the Linux Manual Pages Project is also determined to start using it sooner or later. I did not advocate for this new macro, but since we want to remain able to read all manual pages found in the wild, there is little choice but to support it. At least it is easy to do, they basically copied .Xr.
* Remove the statement that .TQ was "rarely used even in GNU manual pages".Ingo Schwarze2023-10-231-3/+3
| | | | | | | | | | | | | | | | | | | It appears the Linux Manual Pages project started to quite aggressively use .TQ ever for cases where it not only provides no value, but makes formatting worse even when it formats as intended. It's also a bad idea to use it that aggressively because .TQ has particularly catastrophic formatting behaviour on formatters (other than groff and mandoc) that do not support it: It essentially has the effect of omitting the topic of the discussion from the formatted version of the manual page, but in such a way that it does not become apparent to the reader that anything is missing. But whether this is wise or stupid is their problem and none of our business. Either way, we should not call a thing "rarely used" after that is no longer true. Thanks to Alejandro Colomar <alx at kernel org org> for making me aware that the statement is no longer true.
* Support some escape sequences, in particular character escape sequences,Ingo Schwarze2023-10-235-11/+61
| | | | | | | | | | | | | | | | | | | | | | | inside \w arguments, and skip most other escape sequences when measuring the output length in this way because most escape sequences contribute little or nothing to text width: for example, consider font escapes in terminal output. This implementation is very rudimentary. In particular, it assumes that every character has the same width. No attempt is made to detect double-width or zero-width Unicode characters or to take dependencies on output devices or fonts into account. These limitations are hard to avoid because mandoc has to interpolate \w at the parsing stage when the output device is not yet known. I really do not want the content of the syntax tree to depend on the output device. Feature requested by Paul <Eggert at cs dot ucla dot edu>, who also submitted a patch, but i chose to commit this very different patch with almost the same functionality. His input was still very valuable because complete support for \w is out of the question, and consequently, the main task is identifying subsets of the feature that are needed for real-world manual pages and can be supported without uprooting the whole forest.
* Various updates:Ingo Schwarze2023-10-231-61/+105
| | | | | | | | | * document several missing ESCAPE_* constants * some sequences are no longer ignored * more information about what this function is used for * better mark up output arguments * improve some ordering * drop the BUGS section, all that is almost completely fixed now
* update the internal function name roff_res() to roff_expand(),Ingo Schwarze2023-10-231-2/+2
| | | | | it was changed some time ago; patch from Paul <Eggert at cs dot ucla dot edu>
* new regression test for roff.c rev. 1.270:Ingo Schwarze2023-10-224-3/+24
| | | | infinite recursion in macro argument expansion
* While doing delayed expansion of escape sequences in macro arguments,Ingo Schwarze2023-10-221-1/+1
| | | | | | | | | | correctly check for failure of the in-place expansion function. If an argument not only does recursive delayed expansion but infinitely recursive delayed expansion, this bug could result in an ESCAPE_EXPAND assertion failure. Thanks to Eric van Gyzen <vangyzen at FreeBSD> for finding this bug by inspecting FreeBSD source code.
* regression test for roff.c rev. 1.397:Ingo Schwarze2023-10-213-2/+19
| | | | recursive delayed expansion of escape sequences in macro arguments
* When parsing a macro argument results in delayed escape sequenceIngo Schwarze2023-10-212-9/+3
| | | | | | | | | | | | | | expansion, re-check for all contained escape sequences whether they need delayed expansion, not just for the particular escape sequences that triggered delayed expansion in the first place. This is needed because delayed expansion can result in strings containing nested escape sequences recursively needing delayed expansion, too. This fixes an assertion failure in krb5_openlog(3), see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266882 Thanks to Wolfram Schneider <wosch at FreeBSD> for reporting the bug and to Baptiste Daroussin <bapt at FreeBSD> for forwarding the report.
* new entries: .MR and .TP .IP .TPIngo Schwarze2023-10-191-0/+7
|
* Install mandoc.css by default even if man.cgi(8) is not built.Ingo Schwarze2023-10-193-0/+9
| | | | | | It matters because users of "mandoc -T html" typically need it. Issue found in a conversation with Alejandro Colomar <alx at kernel aot org>.
* Support the GNU-specific syntax ".IP \\[bu]" for bullet lists in man(7)Ingo Schwarze2023-10-181-2/+4
| | | | | | | | | | | pages that Alejandro Colomar recommends in the "Lists" subsection of https://man7.org/linux/man-pages/man7/man-pages.7.html#STYLE_GUIDE . For example, this will improve HTML formatting of the first list in the subsection "Feature test macros understood by glibc" on the page https://manpages.debian.org/bookworm/manpages/ftm.7.en.html . Issue reported by Alejandro Colomar <alx at kernel dot org>.
* two new entriesIngo Schwarze2023-10-181-0/+12
|
* Better document the purpose and features of the file mandoc.cssIngo Schwarze2023-10-181-13/+42
| | | | | | and the purpose and limitations of the embedded stylesheet. Triggered by a conversation with Alejandro Colomar <alx at kernel dot org>.
* Include .EX/.EE in the MACRO OVERVIEW and improve its description.Ingo Schwarze2023-10-071-13/+15
| | | | | | | | | | | | | | | It is supported by all major man(7) implementations that G. Branden Robinson and myself are aware of, so calling it "non-portable" can no longer be justified. Using it becomes increasingly more common, so calling it "non-standard" is now misleading. It is certainly useful and not deprecated. While here, also remove the word "non-standard" from the descriptions of several other macros because it is slightly confusing. A formal standard for the man(7) language does not exist. Arguably, Version 7 AT&T UNIX used to be a de-facto standard, but its influence has been waning for 40 years, and various features that Version 7 did not support are now widely used.
* some more ideas from Alejandro ColomarIngo Schwarze2023-08-081-0/+14
|
* adjust after man_validate.c rev. 1.158 improved the error messagesIngo Schwarze2023-04-281-2/+2
|
* Do not rewrite MAN_LP and MAN_P to MAN_PP because doing that causesIngo Schwarze2023-04-283-46/+12
| | | | | | | | | confusing warning messages complaining about macros that don't even appear in the input file. As a welcome side effect, this also shortens the code... Fixing a minibug reported by Alejandro Colomar <alx dot manpages at gmail dot com>.
* spelling fixes from Paul Tagliamonte via tech@ and jmc@Ingo Schwarze2023-04-289-13/+13
|
* 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>.
generated by cgit (git 2.34.1) at 2024-11-11 22:51:49 +0000