Re: [PATCH] nextup.3: minor improvements

[John Gardner]

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'm asking earnestly, as I'm primed to assume overstriking hacks have
already been ruled out (pun intended) as a fallback.

Regards,
— John

On Fri, 9 Aug 2024 at 08:15, Dave Kemper <saint.snit@gmail.com> wrote:

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