Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]

["onf" <onf@disroot.org>]

On Tue Dec 31, 2024 at 7:15 PM CET, Ihor Radchenko wrote:
> >> And this discussion was about using \fC to represent "code" (also,
> >> "fixed width" and tables). We use \fC historically, and it is not very
> >> clear what could be a replacement that does not break Man export
> >> compared to previously produced results.
> >
> > The answer depends on how portable you want your man(7) output to be.  A
> > major reason is that font names are not portable across output
> > devices;...
>
> 1. We want to avoid breaking cases when \fC did work (it is a minimum)
> 2. Ideally, we want things to work in _more_ cases
> 3. Even more ideally, we want things to work in all the cases
>
> If (1) is not possible, compromises will have to be made. I hope that we
> do not have to make compromises.
>
> Also, what if we leave \fC and add \f[CR]/.EX on top?
> AFAIU, the worst case scenario for \fC is that it does nothing. By
> leaving it there, we thus retain old working exports working while also
> adding appropriate format when \f[CR] is supported.

The \f escape sets current font. \fP restores previous font.
What this means is that doing \fC\f[CR]Lorem\fP:
 (1) sets the text Lorem in Courier if font name C or CR exists
 (2) restores previous font if neither font C nor CR exists
 (3) sets font to Courier if both font name C and CR exist

> >> From my reading of man 7 man, .EX/.EE are more suitable for paragraph
> >> markup:
> > ...
> > Yes.  `EX`/`EE` works only with "displays".
>
> May you elaborate about the meaning of "displays"?

Branden will likely provide you with a more detailed description, but
in short, displays are text that is set off from the rest. Example from
groff(7):
  Long words may then look intimidating in the input; a clarifying
  approach might be to use the input line continuation escape sequence
  \newline to place each underlined character on its own input line.
  Thus,
         .nf
         \&\fB: ${\fIvar\fR\c
         \zo\(ul\
         \zp\(ul\c
         \&\fIvalue\fB}
         .fi
  produces
         : ${varopvalue}
  as output.

Checking the manpage's source shows that this is done precisely using
the EX/EE macros:
  Thus,
  .
  .RS
  .EX
  \&.nf
  \[rs]&\[rs]fB: ${\[rs]fIvar\[rs]fR\[rs]c
  \[rs]zo\[rs](ul\[rs]
  \[rs]zp\[rs](ul\[rs]c
  \[rs]&\[rs]fIvalue\[rs]fB}
  \&.fi
  .EE
  .RE
  .
  produces
  .
  .RS
  .EX
  .BI ": ${" var \c
  \zo\(ul\
  \zp\(ul\c
  .IB value }
  .EE
  .RE
  .
  as output.

> Do I understand correctly that blank line is sometimes interpreted as
> vertical spacing and sometimes ignored?

A blank input line is equivalent to .sp unless the .blm request was called
to change this behavior. .blm is groff's invention (see groff_diff(7)).

~ onf