On Thu, May 04, 2017, Eric S. Raymond wrote:
> Doug McIlroy :
> > It would be well to have the Linux manpages project on board for man macro
> > discussions. Is anyone from that project on this mailing list?
> >
> > If not, they should probably be invited to participate. A job for Peter
> > Shafte
Doug McIlroy :
> It would be well to have the Linux manpages project on board for man macro
> discussions. Is anyone from that project on this mailing list?
>
> If not, they should probably be invited to participate. A job for Peter
> Shafter?
I believe I was the last person to modify the Linux m
It would be well to have the Linux manpages project on board for man macro
discussions. Is anyone from that project on this mailing list?
If not, they should probably be invited to participate. A job for Peter Shafter?
Doug
On Thu, May 04, 2017 at 11:30:20AM +0100, Ralph Corderoy wrote:
> > > But - has always meant hyphen in pre-groff troff because it's a lot
> > > more common to want a hyphen in writing than a minus sign.
> >
> > _I_ would claim this interpretation was a mistake.
>
> Well, 7th Ed. documents that hav
Hi Mike,
> > But - has always meant hyphen in pre-groff troff because it's a lot
> > more common to want a hyphen in writing than a minus sign.
>
> _I_ would claim this interpretation was a mistake.
Well, 7th Ed. documents that have `.if n' and `.if t' use - for an
English hyphen and \- for a num
Hi James,
James K. Lowden wrote on Wed, May 03, 2017 at 08:13:18PM -0400:
> IIUC, this debate about how to render - and \- stems from a conflict in
> historical practice. Is the following correct?
>
> When troff was young, terminals were ascii and the - character
> was 0x2d. Manpage gu
Hi Ralph,
Ralph Corderoy wrote on Wed, May 03, 2017 at 03:51:24PM +0100:
> - A hyphen for text, e.g. beer-flavoured ice-cream.
> \- A minus sign in the current font.
> \(miA minus sign in the special font.
> \(hyAnother name for plain `-', so a hyphen for text.
On Wed, 3 May 2017 13:42:55 -0400
Mike Bianchi wrote:
> The - character exists on all keyboards. It is not labeled minus
> or hyphen or endash. It generates the decimal 45 (hex 0x2D, octal
> 055) character. That any *roff processor would give it a different
> meaning is most unfortunate.
IMO
On Wed, May 03, 2017 at 03:51:24PM +0100, Ralph Corderoy wrote:
> :
> :
> - A hyphen for text, e.g. beer-flavoured ice-cream.
> :
> > To my mind - in groff should always default to the ASCII, 7-bit,
> > undistinguished character.
>
> But it's always meant hyphen in
>
> For that to paste from a man page, viewed as UTF-8 TTY,
Erm, I may be missing something, here... but if monospaced hyphens and
minus signs are optically indistinguishable, what's the worth in
differentiating between either?
IMHO, if any change is to be made, it should be with grotty's handli
Mike Bianchi wrote:
I absolutely and completely support this opinion of yours.
Maybe except that it would be nice if some future user could
easily find some documentation and now what to do to get "nice"r
looking output, maybe with some command line argument (variable),
or a configuration file,
Hi Mike,
> Stable, to me, implies not changing much over time, and most changes
> should be backward compatible.
...
> Backward compatible means that all code written to the existing
> definitions should turn out the same results as in the past when
> submitted to new assemblers. (I have nroff do
Folk,
I've been sort of watching from the sidelines here, but am going to toss in my
2 cents.
First, I once heard troff/groff described as the assembly language of type
setting. So to my mind it should be "simple" (as in not too complicated) and
stable. The first goal is forever lost.
Stable
Hi Branden,
> A quick experiment with -Z shows me that groff does still today load
> the S [special] font when the \(pl and \(mi character escapes are
> used.
Yes, my list email from earlier today lists the PostScript glyphs:
https://lists.gnu.org/archive/html/groff/2017-05/msg00028.html
> It's
At 2017-05-02T21:29:39-0400, Doug McIlroy wrote:
> I was previously told that \(mi is the true minus sign. But the
> true minus sign, at least in my mind, must come from the current
> font, so that it comes out right wherever it occurs, even in a
> bold headline like "Fairbanks shivers at -50".
I
Hi Doug,
> Originally \(pl and \(mi came from a fixed font (S) while + and \-
> came from the current font.
That matches CSTR 54 which has
\-Minus sign in the current font
in the table near the beginning and \(pl and \(mi as `Special Character
Names' on the last page.
> As I understand
Branden wrote
Ingo's proposal would not mandate that + and \- come from the special
font.
It also would not mandate that \(pl and \(mi come from the current font.
--
I was previously told that \(mi is the true minus sign. But the
true minus sign, at least in my mind, must come from the cu
Ingo Schwarze 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
|>
Hi,
Ingo Schwarze wrote on Tue, May 02, 2017 at 03:45:01PM +0200:
> 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
Hi Doug,
You didn't quote to whom you're responding so I may be a little
confused.
At 2017-05-01T22:06:38-0400, Doug McIlroy wrote:
> Originally \(pl and \(mi came from a fixed font (S) while + and \-
> came from the current font.
Yes, I believe you're correct, going by CSTR #54. (And, of cours
Hi,
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 clear
Doug McIlroy wrote:
|Originally \(pl and \(mi came from a fixed font (S) while + and \-
|came from the current font. As I understand your comment, groff
|has reversed this troff convention. Additionally groff interprets - as
|a compromise HYPHEN-MINUS.
|
|man groff_char, however, tells the o
Originally \(pl and \(mi came from a fixed font (S) while + and \-
came from the current font. As I understand your comment, groff
has reversed this troff convention. Additionally groff interprets - as
a compromise HYPHEN-MINUS.
man groff_char, however, tells the original state of affairs. What i
Hi Doug,
Doug McIlroy wrote on Mon, May 01, 2017 at 06:55:19PM -0400:
> Ingo Schwarze wrote:
>> If you want a real minus sign (in particular in mathematical
>> formular as opposed to in programming language source code),
>> \- is not a good choise.
> This statement baffles me. That is exactly w
> If you want a real minus sign (in particular in mathematical
> formular as opposed to in programming language source code),
> \- is not a good choise.
This statement baffles me. That is exactly what \- is supposed
to mean: the mathematical minus sign. In particular it is supposed
to match + in
Hi Branden,
G. Branden Robinson wrote on Sun, Apr 30, 2017 at 07:36:03PM -0400:
> I'm working up a man(7) style guide that is sure to be completely
> uncontroversial.
>
> Here is the relevant material from it.
>
> Note that this is related to but independent of Ingo's proposal.
> My preferenc
At 2017-04-30T21:06:12+0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > > > Also, the linitan(1) tool that is a huge part of Debian package QA
> > > > checks man pages for many problems, and I think this is one of
> > > > them.
> > >
> > > I had a look at https://lintian.debian.org/tags-all.html, s
Hi Branden,
> > > Also, the linitan(1) tool that is a huge part of Debian package QA
> > > checks man pages for many problems, and I think this is one of
> > > them.
> >
> > I had a look at https://lintian.debian.org/tags-all.html, searching
> > for `manpage', but didn't spot it?
...
> Here are so
At 2017-04-30T15:07:15+0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > 22 . if '\*[.T]'utf8' \
> > 23 .char - \[hy]
> > 24 .
> >
> > Also, the linitan(1) tool that is a huge part of Debian package QA
> > checks man pages for many problems, and I think this is one of them.
>
>
Hi Ingo,
> That leads to a natural suggestion solving *both* of these problems:
>
> - Make sure *all* output devices (even UTF-8) render - as a
>typographic hyphen (U+2010 HYPHEN) even in manual pages.
>That solves the second problem brought up in this mail.
>Yes, it will require fixi
Hi Branden,
> 22 . if '\*[.T]'utf8' \
> 23 .char - \[hy]
> 24 .
>
> Also, the linitan(1) tool that is a huge part of Debian package QA
> checks man pages for many problems, and I think this is one of them.
I had a look at https://lintian.debian.org/tags-all.html, searching for
Hi Ralph,
i think it is fair to say that our priorities differ slightly here;
i value simplicity for writers slightly higher than you seem to,
and you seem to value typeset (e.g., PDF) output slightly higher
than i tend to. No doubt, both priorities have some merit.
I don't deny that writing goo
Ralph Corderoy writes:
> > INSIDE manual pages, - for \(hy or \- for \(mi is a terrible idea
> > already now because the three main implementations (including groff)
> > don't do that in the quite important -Tutf8 device.
>
> This is because of the bodge to map `-' onto ASCII 45, by Debian
> origi
At 2017-04-26T15:50:26+0100, Ralph Corderoy wrote:
> Writing a man page is writing troff using the -man macros. Always was,
> always will be. It's not some non-troff mark-up language that happens
> to use troff as a back-end. One must be prepared to understand it's not
> just plain text and comm
Hi,
Ingo wrote:
> Besides, writing manual pages absolutely needs to be simple. Manual
> pages must be written by programmers who may not know typography and
> who are not prepared to, and shouldn't be required to, acquire
> specialized knowledge just to write the required manuals together with
>
At 2017-04-25T15:00:26+0200, Ingo Schwarze wrote:
> I don't worry about groff HTML output at all. By the basic design
> of groff, it is unable to produce good HTML, so i basically just
> ignore groff HTML output completely. I fully agree with you that
> i see no need to change it. I'd even go on
Hi,
G. Branden Robinson wrote on Tue, Apr 25, 2017 at 07:26:32AM -0400:
> At 2017-04-25T12:47:25+0200, Carsten Kunze wrote:
>> Carsten Kunze wrote:
>>> Ingo Schwarze hat am 24. April 2017 um 16:39 geschrieben:
>>> Assuming this is considered the right direction, how would one
>>> best implement,
At 2017-04-25T12:47:25+0200, Carsten Kunze wrote:
> > Ingo Schwarze hat am 24. April 2017 um 16:39 geschrieben:
> >
> > Assuming this is considered the right direction, how would one
> > best implement, in doc.tmac-u and an-old.tmac, - == \- == U+002D
> > for all devices?
>
> Isn't it already do
> Ingo Schwarze hat am 24. April 2017 um 16:39 geschrieben:
>
> Assuming this is considered the right direction, how would one
> best implement, in doc.tmac-u and an-old.tmac, - == \- == U+002D
> for all devices?
Isn't it already done for UTF-8 in the files you mentioned?
Both contain:
.if '\*[
Hi,
i think it is clear due to Ralph's extensive analysis that this
whole thing is a mess: Even looking at groff only, for historical
reasons, the input sequences
- \- \(hy \(mi \(en
are handled differently across output devices and across macro sets,
so even using current groff alone
At 2017-04-24T13:08:17+0100, Ralph Corderoy wrote:
> Hi Branden,
>
> > I certainly believe that is the intent of the an and doc macro package
> > authors.
> ...
> > /usr/share/groff/current/tmac/an-old.tmac:681:. char \- \N'45'
> > /usr/share/groff/current/tmac/an-old.tmac:682:. char - \N'45'
>
Hi Branden,
> I certainly believe that is the intent of the an and doc macro package
> authors.
...
> /usr/share/groff/current/tmac/an-old.tmac:681:. char \- \N'45'
> /usr/share/groff/current/tmac/an-old.tmac:682:. char - \N'45'
Yes, but they nobble `-' too, so I could just write a sloppy man
At 2017-04-24T12:16:39+0100, Ralph Corderoy wrote:
> Judging by the lack of suggestions, I'm assuming `\-' is the best bet to
> get a paste-able ASCII `-'.
I certainly believe that is the intent of the an and doc macro package
authors.
$ grep -n -3 45 /usr/share/groff/current/tmac/{an,doc}*.tmac
Hi Branden,
> and those damned hyphens would show up if the source was wrong.
Right, that's the problem.
$ find /etc/machine-id | nroff | xargs ls
ls: cannot access '/etc/machine‐id': No such file or directory
$
Judging by the lack of suggestions, I'm assuming `\-' is the best bet
At 2017-04-23T12:10:03-0400, Doug McIlroy wrote:
> Interesting difference in habits. I never look at groff-ed man pages
> on line--only the default nroff, which is fine for pasting, and more
> importantly, examinable with a full-featured editor.
A lot of (GNU/)Linux systems these days are configur
>> I think it's pretty hopeless to ask for AI that can tell
>> whether a pasted symbol is a hyphen or a minus sign.
>> The answer is likely to depend on whether it is being
>> pasted into a program or into a document.
>
> Right. I'm happy for the typist to put in the effort. Perhaps I'm
> getting
"G. Branden Robinson" wrote:
|At 2017-04-22T16:15:48+0200, Steffen Nurpmeso wrote:
|> "G. Branden Robinson" wrote:
|>|At 2017-04-21T21:56:24-0400, Doug McIlroy wrote:
|>|> I think it's pretty hopeless to ask for AI that can tell
|>|> whether a pasted symbol is a hyphen or a minus sign.
|>|>
At 2017-04-22T16:15:48+0200, Steffen Nurpmeso wrote:
> "G. Branden Robinson" wrote:
> |At 2017-04-21T21:56:24-0400, Doug McIlroy wrote:
> |> I think it's pretty hopeless to ask for AI that can tell
> |> whether a pasted symbol is a hyphen or a minus sign.
> |> The answer is likely to depend on
Doug McIlroy wrote:
|I think it's pretty hopeless to ask for AI that can tell
|whether a pasted symbol is a hyphen or a minus sign.
|The answer is likely to depend on whether it is being
|pasted into a program or into a document.
Of course you are right.
Just ignore my rash messages, please.
"G. Branden Robinson" wrote:
|At 2017-04-21T21:56:24-0400, Doug McIlroy wrote:
|> I think it's pretty hopeless to ask for AI that can tell
|> whether a pasted symbol is a hyphen or a minus sign.
|> The answer is likely to depend on whether it is being
|> pasted into a program or into a docume
Hi,
Doug wrote:
> I think it's pretty hopeless to ask for AI that can tell
> whether a pasted symbol is a hyphen or a minus sign.
> The answer is likely to depend on whether it is being
> pasted into a program or into a document.
Right. I'm happy for the typist to put in the effort. Perhaps I'm
At 2017-04-21T21:56:24-0400, Doug McIlroy wrote:
> I think it's pretty hopeless to ask for AI that can tell
> whether a pasted symbol is a hyphen or a minus sign.
> The answer is likely to depend on whether it is being
> pasted into a program or into a document.
Here's my attempt at clarifying the
I think it's pretty hopeless to ask for AI that can tell
whether a pasted symbol is a hyphen or a minus sign.
The answer is likely to depend on whether it is being
pasted into a program or into a document.
Doug
Ralph Corderoy wrote:
|Clarke wrote:
|> used the simple hyphen character because it was all monospace.
|...
|> If a minus sign appeared in regular text, I always used \(mi.
|
|It was a lot easier then when the was only ASCII `-' and nothing else.
|:-)
..
|I'm no clearer. Except I'm not s
Hi,
Clarke wrote:
> used the simple hyphen character because it was all monospace.
...
> If a minus sign appeared in regular text, I always used \(mi.
It was a lot easier then when the was only ASCII `-' and nothing else.
:-)
Here's how R and TR fonts map onto character 45 in groff.
$ cd /u
Back in the early 1970s, it was called "syntax" when I was
writing programs in assembler and BASIC.
[My first encounter with AT&T Unix manuals and manpages was in
1985, and SYNOPSIS was a new term for me. (I was a hardware
engineer in the rest of the 1970s, and writing user manuals
for data comm
At 2017-04-20T18:04:00-0600, Clarke Echols wrote:
> When I was responsible for all of the manpages in HP's HP-UX (Unix)
> reference manual and online, I always *typeset* with Courier bold, and
> used the simple hyphen character because it was all monospace.
>
> Courier was standard for all literal
When I was responsible for all of the manpages in HP's HP-UX (Unix)
reference manual
and online, I always *typeset* with Courier bold, and used the simple
hyphen character
because it was all monospace.
Courier was standard for all literals in SYNTAX, including command name,
and options
such as
Hi,
If a command is called /bin/foo-bar and it processes a file format
foo-xyzzy, then should their man pages use
foo\-bar
.IR foo\-bar (1)
.IR foo\-xyzzy (5)
...and so on? That's what I thought, `foo-bar' being a hyphen.
Various things around the place collude so both `\-', or the
59 matches
Mail list logo
