emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org, groff@gnu.org
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, 21 Jan 2025 00:52:00 -0600	[thread overview]
Message-ID: <20250121065200.al37mk2nirifampi@illithid> (raw)
In-Reply-To: <87zfjmc32y.fsf@localhost>

[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

Hi Ihor,

At 2025-01-19T14:04:21+0000, Ihor Radchenko wrote:
> "onf" <onf@disroot.org> writes:
> 
> >> I am wondering if the situations like the above should be caught by
> >> groff linter. Currently, they seem not.
> >
> > They actually are:
> > ...
> >   troff:<standard input>:2: warning: cannot select font 'C'
> >   One two three four.
> 
> Sorry, I was not clear.
> What I meant is
> 
> \fBbold \fIitalic\fP\fP

\fP\fP is effectively a no-op.  It switches from the previous font, and
then to the previous font, with a sequence point (so to speak) in
between that changes the identity of the previous font.

Thought of differently, font selection escape sequences, if valid, have
immediate effect.  The parser doesn't keep scanning ahead to see if the
input "really meant it".

There's not really any such thing as "the groff linter".

There are two systems in place: diagnostic messages at (in practice) two
levels: warnings and errors, implemented in the formatter.

The other?  A macro package can, and in groff man(7)'s case, does,
implement checks for idiomatic macro usage.  (Actually, all of groff's
full-service macro packages do this to some extent.)

A macro package has little or no insight into when escape sequences are
used, beyond the instant context in which its input tokens are
encountered.

And to the formatter, the sequence `\fP\fP` is _valid_.  It's simply not
useful.

We don't, at present, have a warning category for valid-but-not-useful
constructs.

One is hoped for in a future groff release.

https://savannah.gnu.org/bugs/?62776

However, I don't see good odds for this becoming such a style warning,
because the way GNU troff's recursive-descent parser is written
currently doesn't offer any support for recognizing this situation.  We
_could_ compare the actual current and previous font selections for
identity and complain then, but I predict with some confidence that
doing so would be a non-starter.  A lot of macro packages are designed
to "reset" various formatting parameters, when a new paragraph starts
for instance.

Such a mechanism could not distinguish between:

.ft R
blah blah blah blah
.if \n[some-register] .do-something
.sp
.ft R

...and your \fP\fP example.  By the time the formatter reads the second
the `\fP` it has long forgotten that it just saw an `\fP`.

And in the example above, whether the font selection changed or not
depends entirely on what the "do-something" macro did, _and_ on whether
"some-register" was assigned a true value.  That's a lot of state to
track.

GNU troff does not keep a history of input tokens it has seen except on
very limited, ad-hoc bases to derive semantics from interpretation of
the _current_ input token(s).  As far as I know, no other *roff keeps
such a history either.

That's why this is hard and unlikely to happen.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2025-01-21  6:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01  7:51 [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)] Xiyue Deng
2024-03-03 13:30 ` Ihor Radchenko
2024-03-12  0:06   ` Xiyue Deng
2024-03-13 11:25     ` Ihor Radchenko
2024-03-14 21:46       ` Jeremy Sowden
2024-05-22  9:54         ` Ihor Radchenko
2024-12-18 17:20         ` G. Branden Robinson
2024-12-22 15:41           ` Ihor Radchenko
2024-12-31 17:00             ` G. Branden Robinson
2024-12-31 18:15               ` Ihor Radchenko
2024-12-31 18:42                 ` onf
2024-12-31 18:54                   ` onf
2025-01-01  9:38                   ` Ihor Radchenko
2025-01-01 12:30                     ` onf
2025-01-02 14:29                       ` onf
2025-01-02 17:47                       ` [BUG] ox-man: Nested markup is broken (was: [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)]) Ihor Radchenko
2025-01-02 21:51                         ` onf
2025-01-03  8:38                           ` [BUG] "\fC" macro in ox-man.el [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.2/lisp/org/)] G. Branden Robinson
2025-01-04  0:23                             ` onf
2025-01-04  6:37                               ` G. Branden Robinson
2025-01-04 20:10                                 ` onf
2025-01-05 15:24                                   ` Lennart Jablonka
2025-01-04 13:26                             ` Ihor Radchenko
2025-01-04 16:22                               ` Dave Kemper
2025-01-04 17:37                                 ` Ihor Radchenko
2025-01-02 12:14                     ` G. Branden Robinson
2025-01-04 12:21                       ` Ihor Radchenko
2025-01-19  7:43                       ` Ihor Radchenko
2025-01-19 13:58                         ` onf
2025-01-19 14:04                           ` Ihor Radchenko
2025-01-19 16:38                             ` onf
2025-01-19 16:43                               ` onf
2025-01-21  6:52                             ` G. Branden Robinson [this message]
2025-01-02 12:38                 ` G. Branden Robinson
2025-01-02 14:21                   ` onf
2025-01-04 12:36                   ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250121065200.al37mk2nirifampi@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=groff@gnu.org \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).