Ingo Schwarze <[email protected]> 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!
