Re: [Groff] : ASCII Minus Sign in man Pages

[Steffen Nurpmeso]

Ingo Schwarze <address@hidden> wrote:
 |Steffen Nurpmeso wrote on Tue, May 02, 2017 at 11:50:31AM +0200:
 |> I now think it is better to revert all those per-macro adjustments
 |> altogether and be pure; if people use \- to get "nicer" (smoother
 |> and finer that is) output then pasting from manual is simply
 |> impossible.
 |
 |That is clearly the worst suggestion so far.  It is not just a

No, it is not.  Noone at all complained when thousands of lines of
rather or completely messed up stuff came into this software after
~2005, and i want to point out that several dozen pages of text
have been emitted to this list on the question whether \- should
be pastable or not.  My, that is me who has nothing countable in
the groff source, which is a pity, my first two sentences of this
thread were, and that is all about it

  I use U+002D hyphen-minus.  The minus sign is a mathematical
  symbol, i would say.

 |matter of "if (some) people".  Take, for example, mdoc(7).  It has
 |been enforcing \- for .Fl since its inception in 4.3BSD-Reno in
 |1990, and that wasn't a new choice even though man(7) does not

Noone at all seems to have been interested to give her some
feedback, look over the rim of his tea cup and enter a discussion,
otherwise we possibly would also have nice -idx options to several
commands.  Then you can't paste it, period.  Add or use the local
macro package to warp that to hyphen-minus upon request, that is
my opinion.

 |enforce rendering of command line options in any particular way,
 |but leaves the choice to the author; but standard practice, in
 |man(7) as well, has been to use \- for command line options since
 |the first release of man(7) in Version 7 AT&T UNIX in 1979.  And
 |that made sense at the time because the minus sign was ASCII 0x2d
 |in nroff(1), you couldn't cut and paste from a manual printed on
 |paper, and the distinction between Unicode U+002D HYPHEN-MINUS and
 |U+2212 MINUS SIGN did not yet exist.

But i think there were already font slots for graphical symbols
that could be addressed, right?  No, they surely have had lust,
coming back from playing Spacewar or SpaceInvaders or so, and have
some nicer graphical symbol.  That is not en par but just like the
one who drives a up to 60l/100km Ferrari because he gives a s..t.
The guys who are really used to the stuff and penetrated it do
things like

  .SH NAME
  deroff, delatex \- remove formatting requests
  .SH SYNOPSIS

I think he does this either because he and everybody else is used
to that for a long time.  I would prefer U+2014 EM DASH, my
PDF-to-text of the POSIX standard ends up with that one.

  The options are
  .TP
  .B -w

  .B Fhdr.next
  fields) of all currently open headers
  (see
  .I symopen
  in
  .IR mach-symbol (3)).

That is absolutely pastable, whether UTF-8 or not.
(I don't count myself among them, as i have sacrificed the good
for the bad, e.g., style for content, much too often myself.  But
now i am here, and i think that is better.)

 |So you propose that we break copy and paste from more or less all
 |manual pages now (including in -Tutf8 output which is the default
 |on terminals in many systems at this point), even though it has
 |been working just fine for almost 40 years?  You must be jesting.
 |
 |No, making the decision at this point in time that \- has to
 |consistently render as U+2212 MINUS SIGN is not an option at all.
 |That's one half of the reason why i suggested to make it render
 |consistently as U+002D HYPHEN-MINUS.
 |
 |> Distributions like Debian can then still easily apply
 |> remappings at well-known places and document it in their
 |> guidelines.
 |
 |So groff should do something that is unusable and ask downstream
 |distributions to fix it up to make it useable?  That guarantees
 |utter confusion and doesn't make any sense whatsoever.  What are
 |other formatters (like mandoc) supposed to do?  Mandoc doesn't even
 |have the distinction of "upstream" and "distribution" to implement
 |such a split in behavior.  Both FreeBSD and OpenBSD use the mandoc
 |code directly from the HEAD of the VCS.

I think a growing number of Linux distributions will follow.
Mandoc is faster and can even markdown now.  I cannot talk for
groff.

 |By the way, in the meantime, i also received support from NetBSD/pkgsrc
 |for my proposal (\- always U+002D, \(mi always U+2212).  That's
 |Ralph, Branden, NetBSD/pkgsrc, and one relevant FreeBSD developer
 |then, and no protest so far from OpenBSD.  I think i'll start
 |preparing patches and submit them to the groff bugtracker when they
 |are ready.

You are free to do whatever you want, of course.  I don't know
actually what i will do when i finally have time for my own roff
clone, i for myself have found what i think is a Solaris stdio bug
as well as a OpenBSD 6.1 grep(1) bug as well what i think is
a OpenBSD 6.0 make bug, but that i won't figure out no more, since
yesterday, and have seen fly by changesets which at least
partially revert Bern commits, a work i have done when
i synchronized my roff clone some years ago, hopefully ok, without
having the possibility to step any further yet with that piece of
metal in my side that my MUA was and in parts still is, -- where
is he, by the way, i hope he is well! --, so _that_is a real mess!

But roff documents \- as the minus sign and if the charset
/ font makes available the minus sign as a graphical symbol and
the writer has chosen to use a graphical symbol then i think she
or he should get a graphical symbol, whether it can be pasted onto
a command line or not.

--steffen
|Soylent Green is people!