> <https://lists.gnu.org/archive/html/groff/2022-06/msg00026.html>.
I must have been blissfully unaware of this discussion. However, I want to caution against the idea that "\c" continues an *input* line. "\c" is something that concerns the *output*. I.e., foo\c bar is *two* input lines (and therefore I believe the input trap request .it should count it as two). This is consistent with other troff behavior, in particular tabs and fields, which are relative to the *input* line. Here is an example (<tab> should be an actual tab character): .ta 10n +20n .fc ^ # ^#\m[black]xxx\m[]#^\ ^#\m[blue]xxx\m[]#^ .br ^#\m[black]xxx\m[]#^\c ^#\m[red]xxx\m[]#^ .\" the following is just decoration .sp -3 .ta 10nC +20nC 0<tab>10<tab>30 .sp -1 \v'0.3v'\ \D'l 0 -0.1m'\D'l 10n 0'\D'l 0 0.1m'\ \D'l 0 -0.1m'\D'l 20n 0'\D'l 0 0.1m' .br This sets up two fields, the first one 10 ens wide and the second 20 ens wide. The first input line centers the text "xxx" in black and in blue in these two fields. The second input line again centers the text "xxx" in black in the first field. This input line ends in a "\c", but this does not continue the input line. The third input line also centers the text "xxx" (in red) in a field, but since a new input line has been started, this again corresponds to the first, 10-ens-wide field (not the second, 20-ens-wide field) so it outputs something that is 10 ens wide, even though this output is now attached to the 10-ens-wide output from the second input line and superficially looks like it is inside the second field of the first input line. If we want to change the semantics of "\c" to mean continuation of the input line, then I believe we should also change this above behavior of tabs and fields, so that the red "xxx" will be in the second field like the blue "xxx".
inputlines.pdf
Description: Adobe PDF document
