* desired .Bk semantics?
@ 2010-07-02 23:43 Ingo Schwarze
2010-07-03 6:54 ` Jason McIntyre
0 siblings, 1 reply; 8+ messages in thread
From: Ingo Schwarze @ 2010-07-02 23:43 UTC (permalink / raw)
To: discuss
Hi,
after much headbanging while trying to understand tmac files,
i guess i finally figured out what .Bk -words is supposed to do.
It seems it has nothing to do with macros, but simply with -
lines in the input file! My impression is that .Bk -words
avoids line breaks inside the output generated from each input
line. Perhaps that's why it is called -words (as opposed to -line).
Duh.
Before i start implementing that - it will be a bit tricky,
because Bk will be the first macro having explicit BLOCKs and
implicit BODYs - i should like to get feedback whether you
1) agree with my analysis
2) agree that is sane semantics
As far as i can see, it does seem at least semi-sane and would
probably fix the remaining .Bk issues in our tree.
But i don't want to implement it and then have everybody yell at
me what a bad idea it is. =:c)
Yours,
Ingo
P.S.
Running the following test file through groff 1.20.1 (NEW groff)
seems to support my analysis. Running it through our old groff
just shows how buggy our old groff is. Oh well...
.Dd July 2, 2010
.Dt BK-BREAK 1
.Os
.Sh NAME
.Nm Bk-break
.Nd handling of word keeps
.Sh SYNOPSIS
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo
.Oo a Oc
.Oo b Oc
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo
.Oo a Oc Oo b Oc
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a b
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a
b
.Oc
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a Oc b
.Ek
.Pp
.Nm
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x x x
.Ar x x x x x x
.Bk -words
.Oo a Oc
b
.Ek
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics?
2010-07-02 23:43 desired .Bk semantics? Ingo Schwarze
@ 2010-07-03 6:54 ` Jason McIntyre
2010-07-03 12:27 ` Kristaps Dzonsons
0 siblings, 1 reply; 8+ messages in thread
From: Jason McIntyre @ 2010-07-03 6:54 UTC (permalink / raw)
To: discuss
On Sat, Jul 03, 2010 at 01:43:20AM +0200, Ingo Schwarze wrote:
> Hi,
>
> after much headbanging while trying to understand tmac files,
> i guess i finally figured out what .Bk -words is supposed to do.
> It seems it has nothing to do with macros, but simply with -
> lines in the input file! My impression is that .Bk -words
> avoids line breaks inside the output generated from each input
> line. Perhaps that's why it is called -words (as opposed to -line).
> Duh.
>
according to mdoc.samples(7) it is useful for "preventing line breaks in
the middle of options", and that is how i've always used it. i just
realised that the same piece of text notes that the effect was once
achieved using the Op macro.
so my understanding is it has nothing to do with keeping "words". but
god knows.
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics?
2010-07-03 6:54 ` Jason McIntyre
@ 2010-07-03 12:27 ` Kristaps Dzonsons
2010-07-03 14:11 ` Jason McIntyre
0 siblings, 1 reply; 8+ messages in thread
From: Kristaps Dzonsons @ 2010-07-03 12:27 UTC (permalink / raw)
To: discuss
>> after much headbanging while trying to understand tmac files,
>> i guess i finally figured out what .Bk -words is supposed to do.
>> It seems it has nothing to do with macros, but simply with -
>> lines in the input file! My impression is that .Bk -words
>> avoids line breaks inside the output generated from each input
>> line. Perhaps that's why it is called -words (as opposed to -line).
>> Duh.
>>
>
> according to mdoc.samples(7) it is useful for "preventing line breaks in
> the middle of options", and that is how i've always used it. i just
> realised that the same piece of text notes that the effect was once
> achieved using the Op macro.
Ingo, if you and Jason think this is worth the effort (and correct),
then by all means. HOWEVER. `Bk' is a turd that should be flushed: it
gives the author unnecessary control over output. This is wrong.
What we should do is ignore `Bk' and follow an easy algorithm for
SYNOPSIS mode regarding breaking between children. This, I think, is
easier for us and manual writers alike.
Is `Bk' used often outside of this where .nr nS 1 is otherwise
unacceptable (like those OpenBSD .9 manuals)?
Kristaps
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics?
2010-07-03 12:27 ` Kristaps Dzonsons
@ 2010-07-03 14:11 ` Jason McIntyre
2010-07-03 16:24 ` Kristaps Dzonsons
0 siblings, 1 reply; 8+ messages in thread
From: Jason McIntyre @ 2010-07-03 14:11 UTC (permalink / raw)
To: discuss
On Sat, Jul 03, 2010 at 02:27:21PM +0200, Kristaps Dzonsons wrote:
> >>after much headbanging while trying to understand tmac files,
> >>i guess i finally figured out what .Bk -words is supposed to do.
> >>It seems it has nothing to do with macros, but simply with -
> >>lines in the input file! My impression is that .Bk -words
> >>avoids line breaks inside the output generated from each input
> >>line. Perhaps that's why it is called -words (as opposed to -line).
> >>Duh.
> >>
> >
> >according to mdoc.samples(7) it is useful for "preventing line breaks in
> >the middle of options", and that is how i've always used it. i just
> >realised that the same piece of text notes that the effect was once
> >achieved using the Op macro.
>
> Ingo, if you and Jason think this is worth the effort (and correct),
> then by all means. HOWEVER. `Bk' is a turd that should be flushed: it
> gives the author unnecessary control over output. This is wrong.
>
i agree (with kristaps).
> What we should do is ignore `Bk' and follow an easy algorithm for
> SYNOPSIS mode regarding breaking between children. This, I think, is
> easier for us and manual writers alike.
>
absolutely! SYNOPSIS is a hugely important part of the page - it's the
first thing people see. and we don;t want it looking like shit. and we
don;t want man page writers fannying around trying to make it look ok.
it should just work sanely.
> Is `Bk' used often outside of this where .nr nS 1 is otherwise
> unacceptable (like those OpenBSD .9 manuals)?
>
it is a synopsis-only thing. obviously we sometimes have mini synopses
outside the main SYNOPSIS section. in those cases we could currently
find Bk. i'm not aware of any other places it would normally occur.
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics?
2010-07-03 14:11 ` Jason McIntyre
@ 2010-07-03 16:24 ` Kristaps Dzonsons
2010-07-03 16:52 ` Jason McIntyre
2010-07-03 17:28 ` desired .Bk semantics? Ingo Schwarze
0 siblings, 2 replies; 8+ messages in thread
From: Kristaps Dzonsons @ 2010-07-03 16:24 UTC (permalink / raw)
To: discuss
[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]
> i agree (with kristaps).
>
>> What we should do is ignore `Bk' and follow an easy algorithm for
>> SYNOPSIS mode regarding breaking between children. This, I think, is
>> easier for us and manual writers alike.
>>
>
> absolutely! SYNOPSIS is a hugely important part of the page - it's the
> first thing people see. and we don;t want it looking like shit. and we
> don;t want man page writers fannying around trying to make it look ok.
> it should just work sanely.
>
>> Is `Bk' used often outside of this where .nr nS 1 is otherwise
>> unacceptable (like those OpenBSD .9 manuals)?
>>
>
> it is a synopsis-only thing. obviously we sometimes have mini synopses
> outside the main SYNOPSIS section. in those cases we could currently
> find Bk. i'm not aware of any other places it would normally occur.
Ingo and Jason,
I propose the following. I've enclosed a patch that demonstrates this.
First, I disabled `Bk' completely.
Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.
Example (mandoc -Owidth=70 ssh.1):
SYNOPSIS
ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address]
[-c cipher_spec] [-D [bind_address:]port] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-L [bind_address:]port:host:hostport] [-l login_name]
[-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-W host:port] [-w local_tun[:remote_tun]] [user@]hostname
[command]
Note: this is after removing the escaped spaces that the manual author
had added here and there.
Example (mandoc -Owidth=70 spamd.8):
spamd [-45bdv] [-B maxblack] [-c maxcon]
[-G passtime:greyexp:whiteexp] [-h hostname] [-l address]
[-M address] [-n name] [-p port] [-S secs] [-s secs]
[-w window] [-Y synctarget] [-y synclisten]
This removes the `Bk' mess and gives a nice, regular algorithm for
formatting in MDOC_SYNPRETTY.
It can/will be trivially extended to the function macros, Fa and Fn and
family.
Thoughts?
Kristaps
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 2026 bytes --]
Index: mdoc_term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/mdoc_term.c,v
retrieving revision 1.168
diff -u -r1.168 mdoc_term.c
--- mdoc_term.c 2 Jul 2010 15:03:14 -0000 1.168
+++ mdoc_term.c 3 Jul 2010 16:26:03 -0000
@@ -72,7 +72,6 @@
static void termp_an_post(DECL_ARGS);
static void termp_aq_post(DECL_ARGS);
static void termp_bd_post(DECL_ARGS);
-static void termp_bk_post(DECL_ARGS);
static void termp_bl_post(DECL_ARGS);
static void termp_bq_post(DECL_ARGS);
static void termp_brq_post(DECL_ARGS);
@@ -98,7 +97,6 @@
static int termp_aq_pre(DECL_ARGS);
static int termp_bd_pre(DECL_ARGS);
static int termp_bf_pre(DECL_ARGS);
-static int termp_bk_pre(DECL_ARGS);
static int termp_bl_pre(DECL_ARGS);
static int termp_bold_pre(DECL_ARGS);
static int termp_bq_pre(DECL_ARGS);
@@ -238,7 +236,7 @@
{ NULL, NULL }, /* Fc */
{ termp_op_pre, termp_op_post }, /* Oo */
{ NULL, NULL }, /* Oc */
- { termp_bk_pre, termp_bk_post }, /* Bk */
+ { NULL, NULL }, /* Bk */
{ NULL, NULL }, /* Ek */
{ termp_bt_pre, NULL }, /* Bt */
{ NULL, NULL }, /* Hf */
@@ -1279,6 +1277,8 @@
if (MDOC_BODY != n->type)
return;
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags &= ~TERMP_KEEP;
p->flags |= TERMP_NOSPACE;
term_word(p, "\\(rB");
}
@@ -1460,6 +1460,8 @@
case (MDOC_BODY):
term_word(p, "\\(lB");
p->flags |= TERMP_NOSPACE;
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags |= TERMP_KEEP;
break;
default:
break;
@@ -2138,37 +2140,6 @@
return(0);
}
-
-/* ARGSUSED */
-static int
-termp_bk_pre(DECL_ARGS)
-{
-
- switch (n->type) {
- case (MDOC_BLOCK):
- break;
- case (MDOC_HEAD):
- return(0);
- case (MDOC_BODY):
- p->flags |= TERMP_PREKEEP;
- break;
- default:
- abort();
- /* NOTREACHED */
- }
-
- return(1);
-}
-
-
-/* ARGSUSED */
-static void
-termp_bk_post(DECL_ARGS)
-{
-
- if (MDOC_BODY == n->type)
- p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
-}
/* ARGSUSED */
static int
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics?
2010-07-03 16:24 ` Kristaps Dzonsons
@ 2010-07-03 16:52 ` Jason McIntyre
2010-07-03 17:25 ` desired .Bk semantics? [UPDATED PATCH] Kristaps Dzonsons
2010-07-03 17:28 ` desired .Bk semantics? Ingo Schwarze
1 sibling, 1 reply; 8+ messages in thread
From: Jason McIntyre @ 2010-07-03 16:52 UTC (permalink / raw)
To: discuss
On Sat, Jul 03, 2010 at 06:24:47PM +0200, Kristaps Dzonsons wrote:
>
> Ingo and Jason,
>
> I propose the following. I've enclosed a patch that demonstrates this.
>
> First, I disabled `Bk' completely.
>
> Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
> SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.
>
> Example (mandoc -Owidth=70 ssh.1):
>
> SYNOPSIS
> ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address]
> [-c cipher_spec] [-D [bind_address:]port] [-e escape_char]
> [-F configfile] [-I pkcs11] [-i identity_file]
> [-L [bind_address:]port:host:hostport] [-l login_name]
> [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
> [-R [bind_address:]port:host:hostport] [-S ctl_path]
> [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname
> [command]
>
> Note: this is after removing the escaped spaces that the manual author
> had added here and there.
>
> Example (mandoc -Owidth=70 spamd.8):
> spamd [-45bdv] [-B maxblack] [-c maxcon]
> [-G passtime:greyexp:whiteexp] [-h hostname] [-l address]
> [-M address] [-n name] [-p port] [-S secs] [-s secs]
> [-w window] [-Y synctarget] [-y synclisten]
>
> This removes the `Bk' mess and gives a nice, regular algorithm for
> formatting in MDOC_SYNPRETTY.
>
> It can/will be trivially extended to the function macros, Fa and Fn and
> family.
>
> Thoughts?
>
spiffing!
i wonder though about disabling Bk...do you mean it just ignores it, or
that the current Bk/Ek in files will cause a problem? i'm not averse to
removing them from pages, but i need to think about our pages being
formatted on another system. for example, for ssh.1 to have a fighting
chance on a non-mandoc system.
i don;t know how practical that is though. i haven;t thought very far
ahead about this. keep the keeps (er) or remove them...
jmc
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics? [UPDATED PATCH]
2010-07-03 16:52 ` Jason McIntyre
@ 2010-07-03 17:25 ` Kristaps Dzonsons
0 siblings, 0 replies; 8+ messages in thread
From: Kristaps Dzonsons @ 2010-07-03 17:25 UTC (permalink / raw)
To: discuss
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
> spiffing!
>
> i wonder though about disabling Bk...do you mean it just ignores it, or
> that the current Bk/Ek in files will cause a problem? i'm not averse to
> removing them from pages, but i need to think about our pages being
> formatted on another system. for example, for ssh.1 to have a fighting
> chance on a non-mandoc system.
>
> i don;t know how practical that is though. i haven;t thought very far
> ahead about this. keep the keeps (er) or remove them...
Here's an updated version of the patch that also addresses `Fn' and `Fa'.
It also correctly uses TERMP_PREKEEP instead of TERMP_KEEP, and dips
into encode() to transcode quoted whitespace into ASCII_NBRSP (such as
the case of `Fa "foo bar"').
Ingo, what do you think?
Kristaps
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 4878 bytes --]
? .mdoc.3.swp
? config.h
? config.log
? foo.1
? foo.1.html
? foo.3
? foo.7
? foo.html
? mandoc
? patch.txt
? relayd.8
? relayd.8.html
? spamd.8
? ssh.1
? ssh.1.html
? regress/output
Index: mdoc_term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/mdoc_term.c,v
retrieving revision 1.169
diff -u -r1.169 mdoc_term.c
--- mdoc_term.c 3 Jul 2010 17:17:15 -0000 1.169
+++ mdoc_term.c 3 Jul 2010 17:25:45 -0000
@@ -72,14 +72,13 @@
static void termp_an_post(DECL_ARGS);
static void termp_aq_post(DECL_ARGS);
static void termp_bd_post(DECL_ARGS);
-static void termp_bk_post(DECL_ARGS);
static void termp_bl_post(DECL_ARGS);
static void termp_bq_post(DECL_ARGS);
static void termp_brq_post(DECL_ARGS);
static void termp_bx_post(DECL_ARGS);
static void termp_d1_post(DECL_ARGS);
static void termp_dq_post(DECL_ARGS);
-static int termp_fd_pre(DECL_ARGS);
+static void termp_fa_post(DECL_ARGS);
static void termp_fo_post(DECL_ARGS);
static void termp_in_post(DECL_ARGS);
static void termp_it_post(DECL_ARGS);
@@ -98,7 +97,6 @@
static int termp_aq_pre(DECL_ARGS);
static int termp_bd_pre(DECL_ARGS);
static int termp_bf_pre(DECL_ARGS);
-static int termp_bk_pre(DECL_ARGS);
static int termp_bl_pre(DECL_ARGS);
static int termp_bold_pre(DECL_ARGS);
static int termp_bq_pre(DECL_ARGS);
@@ -109,6 +107,7 @@
static int termp_dq_pre(DECL_ARGS);
static int termp_ex_pre(DECL_ARGS);
static int termp_fa_pre(DECL_ARGS);
+static int termp_fd_pre(DECL_ARGS);
static int termp_fl_pre(DECL_ARGS);
static int termp_fn_pre(DECL_ARGS);
static int termp_fo_pre(DECL_ARGS);
@@ -161,10 +160,10 @@
{ NULL, NULL }, /* Er */
{ NULL, NULL }, /* Ev */
{ termp_ex_pre, NULL }, /* Ex */
- { termp_fa_pre, NULL }, /* Fa */
+ { termp_fa_pre, termp_fa_post }, /* Fa */
{ termp_fd_pre, NULL }, /* Fd */
{ termp_fl_pre, NULL }, /* Fl */
- { termp_fn_pre, NULL }, /* Fn */
+ { termp_fn_pre, termp_fa_post }, /* Fn */
{ termp_ft_pre, NULL }, /* Ft */
{ termp_bold_pre, NULL }, /* Ic */
{ termp_in_pre, termp_in_post }, /* In */
@@ -238,7 +237,7 @@
{ NULL, NULL }, /* Fc */
{ termp_op_pre, termp_op_post }, /* Oo */
{ NULL, NULL }, /* Oc */
- { termp_bk_pre, termp_bk_post }, /* Bk */
+ { NULL, NULL }, /* Bk */
{ NULL, NULL }, /* Ek */
{ termp_bt_pre, NULL }, /* Bt */
{ NULL, NULL }, /* Hf */
@@ -1279,6 +1278,8 @@
if (MDOC_BODY != n->type)
return;
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
p->flags |= TERMP_NOSPACE;
term_word(p, "\\(rB");
}
@@ -1460,6 +1461,8 @@
case (MDOC_BODY):
term_word(p, "\\(lB");
p->flags |= TERMP_NOSPACE;
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags |= TERMP_PREKEEP;
break;
default:
break;
@@ -1578,7 +1581,13 @@
for (nn = n->child->next; nn; nn = nn->next) {
term_fontpush(p, TERMFONT_UNDER);
+
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags |= TERMP_PREKEEP;
term_word(p, nn->string);
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
+
term_fontpop(p);
if (nn->next)
@@ -1602,12 +1611,20 @@
if (n->parent->tok != MDOC_Fo) {
term_fontpush(p, TERMFONT_UNDER);
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags |= TERMP_PREKEEP;
return(1);
}
for (nn = n->child; nn; nn = nn->next) {
term_fontpush(p, TERMFONT_UNDER);
+
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags |= TERMP_PREKEEP;
term_word(p, nn->string);
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
+
term_fontpop(p);
if (nn->next)
@@ -1622,6 +1639,16 @@
/* ARGSUSED */
+static void
+termp_fa_post(DECL_ARGS)
+{
+
+ if (MDOC_SYNPRETTY & n->flags)
+ p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
+}
+
+
+/* ARGSUSED */
static int
termp_bd_pre(DECL_ARGS)
{
@@ -2140,37 +2167,6 @@
return(0);
}
-
-/* ARGSUSED */
-static int
-termp_bk_pre(DECL_ARGS)
-{
-
- switch (n->type) {
- case (MDOC_BLOCK):
- break;
- case (MDOC_HEAD):
- return(0);
- case (MDOC_BODY):
- p->flags |= TERMP_PREKEEP;
- break;
- default:
- abort();
- /* NOTREACHED */
- }
-
- return(1);
-}
-
-
-/* ARGSUSED */
-static void
-termp_bk_post(DECL_ARGS)
-{
-
- if (MDOC_BODY == n->type)
- p->flags &= ~(TERMP_KEEP | TERMP_PREKEEP);
-}
/* ARGSUSED */
static int
Index: term.c
===================================================================
RCS file: /usr/vhosts/mdocml.bsd.lv/cvs/mdocml/term.c,v
retrieving revision 1.158
diff -u -r1.158 term.c
--- term.c 3 Jul 2010 16:02:12 -0000 1.158
+++ term.c 3 Jul 2010 17:25:45 -0000
@@ -624,7 +624,11 @@
for (i = 0; i < (int)sz; i++) {
if ( ! isgraph((u_char)word[i])) {
- bufferc(p, word[i]);
+ if (TERMP_KEEP & p->flags && ' ' == word[i])
+ bufferc(p, ASCII_NBRSP);
+ else
+ bufferc(p, word[i]);
+
continue;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: desired .Bk semantics?
2010-07-03 16:24 ` Kristaps Dzonsons
2010-07-03 16:52 ` Jason McIntyre
@ 2010-07-03 17:28 ` Ingo Schwarze
1 sibling, 0 replies; 8+ messages in thread
From: Ingo Schwarze @ 2010-07-03 17:28 UTC (permalink / raw)
To: discuss
Hi Kristaps,
Kristaps Dzonsons wrote on Sat, Jul 03, 2010 at 06:24:47PM +0200:
> I propose the following. I've enclosed a patch that demonstrates this.
> First, I disabled `Bk' completely.
I disagree: That is going too far.
Like that, you lose the possibility to keep non-optional arguments
together on the same line. Consider, e.g.
.Nm cut
.Bk -words
.Fl b Ar list
.Ek
.Op Ar n
.Op Ar
.Nm cut
.Bk -words
.Fl c Ar list
.Ek
.Ar
I admit in this case this is not critical because the keep is near
the beginning of the line, but this is how it should be written,
and such necessities can also arise later on the line,
Thus, do not rip .Bk out completely.
It should be available for the rare cases where is is needed,
and it is a standard mdoc(7) macro we cannot just drop.
> Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
> SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.
I disagree: That is going too far.
Like that, you lose the option to allow breaking in the middle of
an .Op or .Oo group. Consider, e.g.
.Nm openssl
.Cm gendsa
.Oo
.Fl aes128 |
.Fl aes192 |
.Fl aes256 |
.Fl des |
.Fl des3
.Oc
...
This could get worse when more ciphers are implemented, and ultimately,
it won't fit on one line any more, giving you very ugly output and no way
to fix it.
I don't oppose automatically assuming implied .Bk around .Op and .Oo
tough, as long as they are on one input line, even though troff
historically decided against that.
That's probably the last mail i can send before teardown of the hack
room, and i don't have time to look at your code right now...
Yours,
Ingo
--
To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-07-03 17:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-02 23:43 desired .Bk semantics? Ingo Schwarze
2010-07-03 6:54 ` Jason McIntyre
2010-07-03 12:27 ` Kristaps Dzonsons
2010-07-03 14:11 ` Jason McIntyre
2010-07-03 16:24 ` Kristaps Dzonsons
2010-07-03 16:52 ` Jason McIntyre
2010-07-03 17:25 ` desired .Bk semantics? [UPDATED PATCH] Kristaps Dzonsons
2010-07-03 17:28 ` desired .Bk semantics? Ingo Schwarze
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).