Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[Tadziu Hoffmann]

> <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