[PATCH] nextup.3: minor improvements

[PATCH] nextup.3: minor improvements

[Vincent Lefevre]

The current "If x is 0" is a bit misleading because "is" is not the
equality test, while this condition should apply to both -0 and 0.
Replace this condition by "If x is equal to 0".

Replace "Nan" by "NaN" (typography used everywhere else).

Signed-off-by: Vincent Lefevre <vincent@vinc17.net>
---
 man/man3/nextup.3 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/man3/nextup.3 b/man/man3/nextup.3
index 285c2bcda..02fdb9bae 100644
--- a/man/man3/nextup.3
+++ b/man/man3/nextup.3
@@ -38,8 +38,8 @@ is the smallest representable negative number in the corresponding type,
 these functions return \-0.
 If
 .I x
-is 0, the returned value is the smallest representable positive number
-of the corresponding type.
+is equal to 0, the returned value is the smallest representable positive
+number of the corresponding type.
 .P
 If
 .I x
@@ -52,7 +52,7 @@ of the corresponding type.
 .P
 If
 .I x
-is Nan,
+is NaN,
 the returned value is NaN.
 .P
 The value returned by
-- 
2.45.2

Re: [PATCH] nextup.3: minor improvements

[Alejandro Colomar]

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

Hi Vincent,

On Wed, Aug 07, 2024 at 12:56:17PM GMT, Vincent Lefevre wrote:
> The current "If x is 0" is a bit misleading because "is" is not the
> equality test, while this condition should apply to both -0 and 0.
> Replace this condition by "If x is equal to 0".

How does 'is' differ semantically from 'is equal to' in this case?

I don't think 'is equal to' does anything different to mean also -0.

> 
> Replace "Nan" by "NaN" (typography used everywhere else).

Ok.

> 
> Signed-off-by: Vincent Lefevre <vincent@vinc17.net>
> ---
>  man/man3/nextup.3 | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/man/man3/nextup.3 b/man/man3/nextup.3
> index 285c2bcda..02fdb9bae 100644
> --- a/man/man3/nextup.3
> +++ b/man/man3/nextup.3
> @@ -38,8 +38,8 @@ is the smallest representable negative number in the corresponding type,
>  these functions return \-0.
>  If
>  .I x
> -is 0, the returned value is the smallest representable positive number
> -of the corresponding type.
> +is equal to 0, the returned value is the smallest representable positive
> +number of the corresponding type.

Please keep semantic newlines.  See man-pages(7).

Have a lovely night!
Alex

>  .P
>  If
>  .I x
> @@ -52,7 +52,7 @@ of the corresponding type.
>  .P
>  If
>  .I x
> -is Nan,
> +is NaN,
>  the returned value is NaN.
>  .P
>  The value returned by
> -- 
> 2.45.2

-- 
<https://www.alejandro-colomar.es/>

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

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

On 2024-08-07 23:19:56 +0200, Alejandro Colomar wrote:
> Hi Vincent,
> 
> On Wed, Aug 07, 2024 at 12:56:17PM GMT, Vincent Lefevre wrote:
> > The current "If x is 0" is a bit misleading because "is" is not the
> > equality test, while this condition should apply to both -0 and 0.
> > Replace this condition by "If x is equal to 0".
> 
> How does 'is' differ semantically from 'is equal to' in this case?

"is" designates the value (it is a short for "has the value").
For instance, in the same man page (with the typo fixed):
"If x is NaN" (saying "is equal to" would be incorrect, because
the equality comparison with NaN is always false).

That's why the sqrt(3) man page has

  If x is +0 (-0), +0 (-0) is returned.

and the cbrt(3) man page has

  If x is +0, -0, positive infinity, [...]

"is equal to" corresponds to the usual equality, as written in
a source code. (IEEE 754-2019 actually uses "equals".)

For zero, one can also say "If x is ±0" as in the IEEE 754 standard.
The IEEE 754 standard also uses "zero" in the sense "±0" (but it
never uses "0" in this sense when there may be an ambiguity, knowing
that in practice, "0" has the same meaning as "+0"). In a condition,
when it says something like "x = 0", this means that x is either +0
or -0 because these values compare equal to each other.

So one could also say "If x is zero".

> I don't think 'is equal to' does anything different to mean also -0.

Note that the glibc manual in info format says for nextup:

  If X = ‘0’ the function returns the smallest positive subnormal
  number in the type of X.

and for nextdown:

  If X = ‘0’ the function returns the smallest negative subnormal
  number in the type of X.

> >  If
> >  .I x
> > -is 0, the returned value is the smallest representable positive number
> > -of the corresponding type.
> > +is equal to 0, the returned value is the smallest representable positive
> > +number of the corresponding type.
> 
> Please keep semantic newlines.  See man-pages(7).

I suppose that the issue is here "long clauses should be split at
phrase boundaries", so that you would like to avoid a split between
"positive" and "number". Perhaps better between "is" and "the".

BTW, it seems that this is often not honored, including in new text
(see e.g. commit c86bb39a117fb593f1ff7b7e729d70166d942446 two months
ago, with a split between "undefined" and "behavior").

And should I introduce a newline after the comma, though it is
currently not present? But this will not eliminate the need for
another line break.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] nextup.3: minor improvements

[Alejandro Colomar]

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

Hi Vincent,

On Thu, Aug 08, 2024 at 04:56:36AM GMT, Vincent Lefevre wrote:
> On 2024-08-07 23:19:56 +0200, Alejandro Colomar wrote:
> > Hi Vincent,
> > 
> > On Wed, Aug 07, 2024 at 12:56:17PM GMT, Vincent Lefevre wrote:
> > > The current "If x is 0" is a bit misleading because "is" is not the
> > > equality test, while this condition should apply to both -0 and 0.
> > > Replace this condition by "If x is equal to 0".
> > 
> > How does 'is' differ semantically from 'is equal to' in this case?
> 
> "is" designates the value (it is a short for "has the value").
> For instance, in the same man page (with the typo fixed):
> "If x is NaN" (saying "is equal to" would be incorrect, because
> the equality comparison with NaN is always false).
> 
> That's why the sqrt(3) man page has
> 
>   If x is +0 (-0), +0 (-0) is returned.
> 
> and the cbrt(3) man page has
> 
>   If x is +0, -0, positive infinity, [...]
> 
> "is equal to" corresponds to the usual equality, as written in
> a source code. (IEEE 754-2019 actually uses "equals".)
> 
> For zero, one can also say "If x is ±0" as in the IEEE 754 standard.
> The IEEE 754 standard also uses "zero" in the sense "±0" (but it
> never uses "0" in this sense when there may be an ambiguity, knowing
> that in practice, "0" has the same meaning as "+0"). In a condition,
> when it says something like "x = 0", this means that x is either +0
> or -0 because these values compare equal to each other.

Hmmm, I see.  Thanks!  I think "If x is ±0" is the clearest way to say
it.  I'm not sure if that glyph is available everywhere, though.  How
about "If x is 0 or -0"?

> 
> So one could also say "If x is zero".
> 
> > I don't think 'is equal to' does anything different to mean also -0.
> 
> Note that the glibc manual in info format says for nextup:
> 
>   If X = ‘0’ the function returns the smallest positive subnormal
>   number in the type of X.
> 
> and for nextdown:
> 
>   If X = ‘0’ the function returns the smallest negative subnormal
>   number in the type of X.
> 
> > >  If
> > >  .I x
> > > -is 0, the returned value is the smallest representable positive number
> > > -of the corresponding type.
> > > +is equal to 0, the returned value is the smallest representable positive
> > > +number of the corresponding type.
> > 
> > Please keep semantic newlines.  See man-pages(7).
> 
> I suppose that the issue is here "long clauses should be split at
> phrase boundaries", so that you would like to avoid a split between
> "positive" and "number".

Yes.

> Perhaps better between "is" and "the".

LGTM.

> BTW, it seems that this is often not honored, including in new text
> (see e.g. commit c86bb39a117fb593f1ff7b7e729d70166d942446 two months
> ago, with a split between "undefined" and "behavior").

Hmmm, that's an oversight from my part; sorry.  But I would say it's
rather not often.  That's by far the most repeated issue in incoming
patches, and I try to always require contributors to fix them.  :)

I'll fix that one, with a 'Reported-by:' you.

> And should I introduce a newline after the comma, though it is
> currently not present? But this will not eliminate the need for
> another line break.

Sure, thanks!

Have a lovely day!
Alex


-- 
<https://www.alejandro-colomar.es/>

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

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

Hi Alejandro,

On 2024-08-08 10:07:35 +0200, Alejandro Colomar wrote:
> On Thu, Aug 08, 2024 at 04:56:36AM GMT, Vincent Lefevre wrote:
> > For zero, one can also say "If x is ±0" as in the IEEE 754 standard.
> > The IEEE 754 standard also uses "zero" in the sense "±0" (but it
> > never uses "0" in this sense when there may be an ambiguity, knowing
> > that in practice, "0" has the same meaning as "+0"). In a condition,
> > when it says something like "x = 0", this means that x is either +0
> > or -0 because these values compare equal to each other.
> 
> Hmmm, I see.  Thanks!  I think "If x is ±0" is the clearest way to say
> it.  I'm not sure if that glyph is available everywhere, though.  How
> about "If x is 0 or -0"?

Since ± is in latin1, I suppose that the glyph is available
everywhere. However, some English speakers might still use
ASCII-based locales. I'm going to send a new patch with
"If x is +0 or -0" (it is better to give the + sign explicitly,
and this is also nicer for symmetry).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[PATCH v2] nextup.3: minor improvements

[Vincent Lefevre]

The current "If x is 0" condition is a bit misleading because "is"
is not the equality test (just like when saying "x is NaN") and 0
as a FP number stands for +0, while this condition should apply to
both -0 and +0.
Replace this condition by "If x is +0 or -0".

Replace "Nan" by "NaN" (typography used everywhere else).

Signed-off-by: Vincent Lefevre <vincent@vinc17.net>
---
 man/man3/nextup.3 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/man/man3/nextup.3 b/man/man3/nextup.3
index 285c2bcda..568f3b13f 100644
--- a/man/man3/nextup.3
+++ b/man/man3/nextup.3
@@ -38,8 +38,9 @@ is the smallest representable negative number in the corresponding type,
 these functions return \-0.
 If
 .I x
-is 0, the returned value is the smallest representable positive number
-of the corresponding type.
+is +0 or \-0,
+the returned value is
+the smallest representable positive number of the corresponding type.
 .P
 If
 .I x
@@ -52,7 +53,7 @@ of the corresponding type.
 .P
 If
 .I x
-is Nan,
+is NaN,
 the returned value is NaN.
 .P
 The value returned by
-- 
2.45.2

Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

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

[looping in groff@gnu]

At 2024-08-08T10:07:35+0200, Alejandro Colomar wrote:
> On Thu, Aug 08, 2024 at 04:56:36AM GMT, Vincent Lefevre wrote:
> > On 2024-08-07 23:19:56 +0200, Alejandro Colomar wrote:
> > > Hi Vincent,
> > > 
> > > On Wed, Aug 07, 2024 at 12:56:17PM GMT, Vincent Lefevre wrote:
> > > > The current "If x is 0" is a bit misleading because "is" is not
> > > > the equality test, while this condition should apply to both -0
> > > > and 0.  Replace this condition by "If x is equal to 0".
> > > 
> > > How does 'is' differ semantically from 'is equal to' in this case?
> > 
> > "is" designates the value (it is a short for "has the value").
> > For instance, in the same man page (with the typo fixed):
> > "If x is NaN" (saying "is equal to" would be incorrect, because
> > the equality comparison with NaN is always false).
> > 
> > That's why the sqrt(3) man page has
> > 
> >   If x is +0 (-0), +0 (-0) is returned.
> > 
> > and the cbrt(3) man page has
> > 
> >   If x is +0, -0, positive infinity, [...]
> > 
> > "is equal to" corresponds to the usual equality, as written in
> > a source code. (IEEE 754-2019 actually uses "equals".)
> > 
> > For zero, one can also say "If x is ±0" as in the IEEE 754 standard.
> > The IEEE 754 standard also uses "zero" in the sense "±0" (but it
> > never uses "0" in this sense when there may be an ambiguity, knowing
> > that in practice, "0" has the same meaning as "+0"). In a condition,
> > when it says something like "x = 0", this means that x is either +0
> > or -0 because these values compare equal to each other.
> 
> Hmmm, I see.  Thanks!  I think "If x is ±0" is the clearest way to say
> it.  I'm not sure if that glyph is available everywhere, though.  How
> about "If x is 0 or -0"?

I think it's reasonable to assume that it's available.[1]  groff's
terminal output devices will either output it as-is or substitute a
fallback.

$ printf '±\n' | groff -K utf8 -T ascii | cat -s
+-

An argument could be made that this fallback should render "+/-"
instead.

With low-capability devices, there's often no single best answer to how
one should limp along.

In groff, of course, you can ask an output device whether it supports a
given glyph and define a string appropriately--but the first part of
that is not portable to formatters that don't implement groff
extensions, and doing so could rouse the ire of Ingo Schwarze's
mandoc(1).

Regards,
Branden

[1] The ± symbol was in the Seventh Edition Unix troff glyph repertoire
    and is also in ISO 8859-1.  I conclude that it's as portable as
    anything not in US-ASCII gets.

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

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

On 2024-08-08 07:16:03 -0500, G. Branden Robinson wrote:
> At 2024-08-08T10:07:35+0200, Alejandro Colomar wrote:
> > Hmmm, I see.  Thanks!  I think "If x is ±0" is the clearest way to say
> > it.  I'm not sure if that glyph is available everywhere, though.  How
> > about "If x is 0 or -0"?
> 
> I think it's reasonable to assume that it's available.[1]  groff's
> terminal output devices will either output it as-is or substitute a
> fallback.
> 
> $ printf '±\n' | groff -K utf8 -T ascii | cat -s
> +-
> 
> An argument could be made that this fallback should render "+/-"
> instead.
> 
> With low-capability devices, there's often no single best answer to how
> one should limp along.

FYI, +-0 could be interpreted by the reader as in C, where a unary
minus operator is applied, then a unary plus operator. And about +/-0,
the "/" is already used a the division operator, so that this doesn't
help parsing.

So ideally, the fallback for "±0" should be "+0 or -0", which is
much more readable and less ambiguous than "+-0" or "+/-0". But
this would imply the following:

> In groff, of course, you can ask an output device whether it supports a
> given glyph and define a string appropriately--but the first part of
> that is not portable to formatters that don't implement groff
> extensions, and doing so could rouse the ire of Ingo Schwarze's
> mandoc(1).

Anyway, currently, for consistency, this should be "+0 or -0",
as this is already used:

cventin:~/software/man-pages> grep -r '\+0 or' man
man/man3/tgamma.3:Pole error: \fIx\fP is +0 or \-0
man/man3/tgamma.3:an argument of +0 or \-0 incorrectly produced a domain error
man/man3/pow.3:is +0 or \-0,
man/man3/pow.3:is +0 or \-0,
man/man3/atan2.3:is +0 or \-0, \-pi/2 is returned.
man/man3/atan2.3:is +0 or \-0, pi/2 is returned.
man/man3/cosh.3:is +0 or \-0, 1 is returned.
man/man3/erfc.3:is +0 or \-0, 1 is returned.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] nextup.3: minor improvements

[Dave Kemper]

On Thu, Aug 8, 2024 at 7:59 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> FYI, +-0 could be interpreted by the reader as in C, where a unary
> minus operator is applied, then a unary plus operator. And about +/-0,
> the "/" is already used a the division operator, so that this doesn't
> help parsing.

It helps *some*, in that "/" can't be a unary operator, so it signals
to the reader that +/-0 isn't a C expression.  It also helps that
"+/-" has been used in other contexts where ± is unavailable, so some
readers might already be familiar with it.

The latter point argues in favor of Branden's idea to change groff's
fallback from +- to +/-.

> So ideally, the fallback for "±0" should be "+0 or -0", which is
> much more readable and less ambiguous than "+-0" or "+/-0".

That is a clearer phrasing, but unfortunately, there's no way to make
that transformation an automatic fallback in the man macros (unless
Tadziu swoops in to prove me wrong); the whole phrase would have to be
specifically coded that way in the individual page--something that,
aside from being discouraged in man pages, is less reliable than one
might hope (http://savannah.gnu.org/bugs/?65403#comment0).

> Anyway, currently, for consistency, this should be "+0 or -0",
> as this is already used:

...which luckily makes all the above moot.

Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

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

Hi John,

At 2024-08-09T15:53:30+1000, John Gardner wrote:
> Hi Vincent,

Not to horn in, but I think I'm better situated to venture opinions or
background on implementation decisions taken in groff than Vincent is.

> So ideally, the fallback for "±0" should be "+0 or -0", which is
> > much more readable and less ambiguous than "+-0" or "+/-0".
> 
> For approximating ± in ASCII, is there some reason \z_+0 hasn't been
> considered?

You anticipated the answer.

> I'm asking earnestly, as I'm primed to assume overstriking hacks have
> already been ruled out (pun intended) as a fallback.

\z _is_ an overstriking hack.

From groff's Texinfo manual (slightly altered):

 -- Escape sequence: \o'abc...'
     Overstrike the glyphs of characters A, B, C, ...; the glyphs are
     centered, written, and the drawing position advanced by the widest
     of the glyphs.

 -- Escape sequence: \zc
     Format the character C with zero width; that is, without advancing
     the drawing position.  Use '\z' to overstrike glyphs aligned to
     their left edges, in contrast to '\o''s centering.

All of the terminal output devices groff supports lack overstriking
support.

Resolving <https://savannah.gnu.org/bugs/?63583> (waiting on me) is a
prerequisite to doing anything about that.

We would also need a new "DESC" file keyword to declare overstriking
support in output devices, and a way to query this parameter from the
GNU troff language.[1]  (This would also be useful for Tektronix 4014
support.)

The enthusiastic aficionados of the Western Electric/Teletype
Corporation Model 37, including (it would seem) many less(1) users,
could then run wild with TERM=tty37.

tty37|model 37 teletype,
        OTbs, hc, os, xon,
        bel=^G, cr=\r, cub1=^H, cud1=\n, cuu1=\E7, hd=\E9, hu=\E8,
        ind=\n,

I'm open to correction by Vincent or anyone else.  :)

Regards,
Branden

[1] Straw man:

    A.  A new keyword "overstrike" or "has-overstriking" would be
        recognized by libdriver and/or libgroff.  (In practice, only
        grotty(1) would need to bother checking for it; any driver for a
        typesetter can assume that overstriking is possible.)

    B.  A new conditional expression operator, "T", would take a
        delimited argument naming an output device capability.

So you might have something like this:

.ie T'has-overstriking' .fchar \[+-] \o'_+'
.el                     .fchar \[+-] +/\-

The feature window for groff 1.24 is closing (maybe in a month?), though
I still want to get #63583 landed before freezing the formatter, even
though it's strictly just an output driver change, on the off chance
that I _have_ to change something in the formatter to support it, and
because Lennart Jablonka has demonstrated the patience of a saint (as
have Deri James and TANAKA Takuji_).

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

Re: [PATCH] nextup.3: minor improvements

[Damian McGuckin]

On Fri, 9 Aug 2024, John Gardner wrote:

>> So ideally, the fallback for "?0" should be "+0 or -0", which is
>> much more readable and less ambiguous than "+-0" or "+/-0".
>
>> For approximating ? in ASCII, is there some reason \z_+0 hasn't been
>> considered?

I had forgotten that approach.

The problem of discussing signed zeros goes beyond way beyond nextup.3.

I had a discussion with someone wanting to use the UTF-8 character that 
renders like \z_+0 inside comments in a C program to better document 
branch cuts for complex numbers. I was not enthused because I use an 
editor that does not understand UTF-8.

But I think the fact that "...+0 and -0" are used already makes the 
argument for consistency pretty compelling.

My 2c - Damian

Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

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

Hi John,

At 2024-08-09T16:41:11+1000, John Gardner wrote:
> [I wrote:]
> > All of the terminal output devices groff supports lack overstriking
> > support.
> 
> Whoops. I forgot that what I was seeing in less(1) was actually duped

I don't think it was duped.  It was being clever.  There is lots of
cleverness in less(1).  Some of it makes me cringe.

> using an underline effect. On that note, am I right to assume that
> \fI+\fP0 is equally implausible by virtue of terminals diverging
> wildly in their italicisation support? (Underlining, obliquity,
> ignoring the effect outright, etc).

Not equally implausible.  Most terminals one encounters support enough
of what ECMA-48 calls "graphic renditions" that, _generally_, in your
exhibit the '+' and the '0' will appear in visually distinguishable
styles.  But little beyond that can be said: they might be different
colors, the plus sign might be in standout (reverse video) mode, it
might be underlined, and so on.

And a document author, particularly of a man page, does _not_ want to
rely solely on text style changes to communicate meaning.  Such things
go away when people do unspeakable things like copying and pasting
chunks of man pages into email messages, losing all formatting.  As a
rule it's prudent to ensure that your meaning is adequately conveyed
when the text is read aloud.  That's a laudable practice in all writing.

(I assume that Slack and Discord clients support "rich text", and
eagerly convert each word of styled text into 100kiB of CSS-ful HTML
overhead.[1])

> That reminds me (and I'm being dead serious here), if anybody knows
> where a Model 37 can be acquired in 2024, *please* let me know. (I
> spent all arvo yesterday searching… seriously).

I read somewhere recently, possibly on the TUHS or COFF lists, that
Model 33 machines experienced an active and deliberate period of
junking.  And as far as I know Model 37s were not very common outside of
Bell Labs, which partly explains why such devices were known mainly as
"ASR 33"s, a misnomer in multiple respects.[2]  Who needs a Greek box,
anyway?

Good luck.  If you are ever successful I may send you a draft notice
enlisting you in the improvement of groff's hardcopy terminal support.

> Why stop there? Such a conditional could match against a named field
> (and optional value) in an output driver description (DESC) file,
> whether it's recognised by Groff or not. Something like:
> 
> .if T unicode \{
> .if T res > 50 \{
> 
> I mean, if we're gonna extend the syntax to include something this
> niche, we may as well go all the way.

Much of the machinery is already in place for this.

Numeric expressions are already valid conditional expressions, so all
we'd need here is a syntax for interpolating an output device parameter.

As it happens, `\T` is _not_ yet taken.  So I'd write your thought
experiment as follows.

.if '\?\T"unicode"\?'\?1\?' .tm hooray! we've got Unicode!
.if \T'res'>50 .tm output device has good resolution

Except in AT&T troff compatibility mode, switching up delimiters when
nesting them is not necessary, but doing so can be kind to humans.

And yes, there's a story behind all those wacky `\?` things.

---snip---
5.23.1 Operators in Conditionals
--------------------------------

In 'if', 'ie', and 'while' requests, in addition to the numeric
expressions described in *note Numeric Expressions::, several Boolean
operators are available; the members of this expanded class are termed
"conditional expressions".
[...]
   If the first argument to an 'if', 'ie', or 'while' request begins
with a non-alphanumeric character apart from '!' (see below), it
performs an output comparison test.  (2) (*note Operators in
Conditionals-Footnote-2::)

'XXX'YYY'
     True if formatting the comparands XXX and YYY produces the same
     output commands.  The delimiter need not be a neutral apostrophe:
     the output comparison operator accepts the same delimiters as most
     escape sequences; see *note Delimiters::.  This "output comparison
     operator" formats XXX and YYY in separate scratch buffers; after
     the comparison, the resulting data are discarded.
[...]
     Surround the comparands with '\?' to avoid formatting them; this
     causes them to be compared character by character, as with string
     comparisons in other programming languages.

          .ie "\?|\?"\?\fR|\fP\?" true
          .el false
              => false

     Since GNU 'troff' reads comparands protected with '\?' in copy mode
     (*note Copy Mode::), they need not even be valid 'groff' syntax.
     The escape character is still lexically recognized, however, and
     consumes the next character.

          .ds a \[
          .ds b \[
          .if '\?\*a\?'\?\*b\?' a and b equivalent
          .if '\?\\?'\?\\?' backslashes equivalent
              => a and b equivalent
---end snip---

(Anyone who hates the word "comparand" can blame me.)

I don't know if we'd want to support a `\T[]` syntax as well.  Maybe.

Regards,
Branden

[1] I am informed that these technologies, along with GitHub Merge
    Requests, are the only means of collaboration that developers need
    take seriously these days.  Email is for old men attempting to
    thwart all progress.

    https://salsa.debian.org/dep-team/deps/-/merge_requests/8

    One can almost see Mark Shuttleworth, or someone of identical
    properties,[3] holding the control bar of a marionette.

[2] "Teletype" was (is?) a trademark, and thus should not be used as a
    noun.  "ASR" was not a model identifier, but an option, and that
    option specifically designated a unit _without a keyboard_.  One is
    not going to emulate Thompson and Ritchie that way.  What people
    _mean_ when uttering the slovenly, Eric-Raymondesque "ASR-33
    teletype" locution is closer to:

    "Western Electric (or Teletype Corporation) Model 33 (or 37) KSR
    (teleprinter or teletypewriter)"

    ...where "KSR" means "keyboard send and receive".

    There are many ways to abbreviate that lengthy identifer; "ASR-33
    teletype" is a poor one.

    I don't claim to know whether the vertically integrated structure of
    AT&T, Western Electric, and the Teletype Corporation was stable
    throughout the lifetime of these products.  Regulated monopolies
    lead to fascinating (and/or dismaying) ownership structures.[4]

[3] Like Luca Bocassi plus one billion dollars?
[4] https://coppolacomment.substack.com/p/thames-water-and-its-dividends

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

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

On 2024-08-09 15:53:30 +1000, John Gardner wrote:
> Hi Vincent,
> 
> > So ideally, the fallback for "±0" should be "+0 or -0", which is
> > much more readable and less ambiguous than "+-0" or "+/-0".
> 
> For approximating ± in ASCII, is there some reason \z_+0 hasn't been
> considered?

I don't like that at all. I really see a "+" underlined, so it is
confusing. Moreover, the information is not kept by copy-paste,
and it is not rendered as wanted with "xterm +ulc" (to replace
underline by color). And I don't think that it will correctly be
interpreted by screen readers.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH] nextup.3: minor improvements

[G. Branden Robinson]

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

Hi John,

...butting in on your dialogue with Vincent again...

At 2024-08-09T19:38:48+1000, John Gardner wrote:
>> I really see a "+" underlined
> 
> Is it visually distinct from an ordinary underscore? I merely ask now
> out of curiosity, as Brandan explained why overstriking is a no-go.

If the terminal device has sufficient vertical resolution and can be
bothered, yes.  gnome-terminal does at its default font size, at least
for me.  With xterm, using Xft fonts, I have to jack the type size up to
somewhere between 24 and 36 inclusive before they are distinguishable.

And that's not taking into account the possibility of baseline rule and
underrule (cf. under_score_) glyphs, which are things that exist in AT&T
and GNU troffs.  Neither has a Unicode code point, though, so I wouldn't
hold my breath for support in terminal emulators.

Regards,
Branden

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

Re: [PATCH] nextup.3: minor improvements

[Vincent Lefevre]

On 2024-08-09 19:38:48 +1000, John Gardner wrote:
> Hi Vincent,
> 
> > I really see a "+" underlined
> 
> Is it visually distinct from an ordinary underscore? I merely ask now out
> of curiosity, as Brandan explained why overstriking is a no-go.

The underline bar is slightly different from an underscore, but
this is not the issue. What matters is that the underlined "+"
is very different from the ± character: in this ± character,
the "+" part and the "-" part have the same width, but in the
underlined "+", the underline bar is larger than the "+";
moreover, the underline bar is below the baseline.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH v2] nextup.3: minor improvements

[Alejandro Colomar]

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

Hi Vincent,

On Thu, Aug 08, 2024 at 01:56:10PM GMT, Vincent Lefevre wrote:
> The current "If x is 0" condition is a bit misleading because "is"
> is not the equality test (just like when saying "x is NaN") and 0
> as a FP number stands for +0, while this condition should apply to
> both -0 and +0.
> Replace this condition by "If x is +0 or -0".
> 
> Replace "Nan" by "NaN" (typography used everywhere else).
> 
> Signed-off-by: Vincent Lefevre <vincent@vinc17.net>

Patch applied.  Thanks!

Have a lovely day!
Alex

> ---
>  man/man3/nextup.3 | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/man/man3/nextup.3 b/man/man3/nextup.3
> index 285c2bcda..568f3b13f 100644
> --- a/man/man3/nextup.3
> +++ b/man/man3/nextup.3
> @@ -38,8 +38,9 @@ is the smallest representable negative number in the corresponding type,
>  these functions return \-0.
>  If
>  .I x
> -is 0, the returned value is the smallest representable positive number
> -of the corresponding type.
> +is +0 or \-0,
> +the returned value is
> +the smallest representable positive number of the corresponding type.
>  .P
>  If
>  .I x
> @@ -52,7 +53,7 @@ of the corresponding type.
>  .P
>  If
>  .I x
> -is Nan,
> +is NaN,
>  the returned value is NaN.
>  .P
>  The value returned by
> -- 
> 2.45.2
> 
> 

-- 
<https://www.alejandro-colomar.es/>

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