[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/
From: |
onf |
Subject: |
Re: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)] |
Date: |
Tue, 31 Dec 2024 19:42:52 +0100 |
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