discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: discuss@mdocml.bsd.lv
Subject: Re: more spacing badness
Date: Wed, 22 Sep 2010 01:05:13 +0200	[thread overview]
Message-ID: <20100921230513.GC9516@iris.usta.de> (raw)
In-Reply-To: <4C90EC16.8010002@bsd.lv>

Hi Kristaps,

Kristaps Dzonsons wrote on Wed, Sep 15, 2010 at 05:53:58PM +0200:
> Jason McIntyre wrote:

>> so i tried:
>> 
>> 	.Nm vi\ \&
>> 
>> old and new groff produce:
>> 
>> 	vi  [-eFRrS] [-c cmd] [-t tag] [-w size] [file ...]
>> 
>> but mandoc seems to inject a tab:
>> 
>> 	vi    [-eFRrS] [-c cmd] [-t tag] [-w size] [file ...]

> My last commit fixes this in a general way.  The problem was "\ \&"
> being read as the string length.  Now string length calculations (for
> -Tascii, -Tpdf, and -Tps) all take into account escapes.  This lifts a
> long-standing feature request in the TODO.

WOW, great.
I wouldn't have thought that could be done with so little code.

Admittedly, it's a bit of code duplication, but by far less annoying
than i would have expected.  And it's very nice to have from a
user perspective.  Thanks!


Of course, i was eager to see whether Jason's "vi\ \&" would now work.
Guess what - it didn't.  I first had to fix *two* bugs in my own code.

First, my favourite function term_flushline() handled trailing white
space correctly, but not trailing escaped blank characters.  In the
initial parsing loop, escaped whitespace is counted as normal
characters, then in the final output loop, it gets converted to
normal blanks, and finally, normal blanks (which break out of the
initial parsing loop) are counted again, so trailing escaped blanks
ended up being counted twice against the column width.

Having fixed that one, Jason's "vi\ \&" still wouldn't work.
The reason was a quirk implemented for mdoc's .Bl -hang lists.
In such lists, when the head is wider than the declared head
width, the body gets pushed ahead to make room for the head;
when the head is shorter, the body gets aligned at the declared
position.  The quirk being that when the head is exactly one
character shorter than the declared width, the body gets pulled
back one character - for whatever reason.  That quirk got triggered
and defeated Jason's nicely escaped blank.

So, the second fix is to remove the -hang flag from the SYNOPSIS
.Nm block handling.  I don't remember why i put that flag there
in the first place, it is clearly not needed.  The width is
calculated such that the header will always fit, so pushing ahead
is never needed, and we certainly do not want to pull back.

OK?

Yours,
  Ingo


Index: mdoc_term.c
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/mdoc_term.c,v
retrieving revision 1.104
diff -u -p -r1.104 mdoc_term.c
--- mdoc_term.c	20 Sep 2010 20:02:27 -0000	1.104
+++ mdoc_term.c	21 Sep 2010 22:34:20 -0000
@@ -1027,7 +1027,7 @@ termp_nm_pre(DECL_ARGS)
 		synopsis_pre(p, n->parent);
 
 	if (MDOC_HEAD == n->type && n->next->child) {
-		p->flags |= TERMP_NOSPACE | TERMP_NOBREAK | TERMP_HANG;
+		p->flags |= TERMP_NOSPACE | TERMP_NOBREAK;
 		p->rmargin = p->offset + term_len(p, 1) +
 		    (NULL == n->child ? term_strlen(p, m->name) :
 		     MDOC_TEXT == n->child->type ?
@@ -1049,7 +1049,7 @@ termp_nm_post(DECL_ARGS)
 
 	if (MDOC_HEAD == n->type && n->next->child) {
 		term_flushln(p);
-		p->flags &= ~(TERMP_NOBREAK | TERMP_HANG);
+		p->flags &= ~TERMP_NOBREAK;
 	} else if (MDOC_BODY == n->type && n->child) {
 		term_flushln(p);
 		p->flags &= ~TERMP_NOLPAD;
Index: term.c
===================================================================
RCS file: /cvs/src/usr.bin/mandoc/term.c,v
retrieving revision 1.50
diff -u -p -r1.50 term.c
--- term.c	21 Sep 2010 22:33:41 -0000	1.50
+++ term.c	21 Sep 2010 22:34:20 -0000
@@ -130,6 +130,7 @@ term_flushln(struct termp *p)
 	size_t		 vbl;   /* number of blanks to prepend to output */
 	size_t		 vend;	/* end of word visual position on output */
 	size_t		 bp;    /* visual right border position */
+	size_t		 dv;    /* temporary for visual pos calculations */
 	int		 j;     /* temporary loop index for p->buf */
 	int		 jhy;	/* last hyph before overflow w/r/t j */
 	size_t		 maxvis; /* output position of visible boundary */
@@ -233,7 +234,9 @@ term_flushln(struct termp *p)
 				j = i;
 				while (' ' == p->buf[i])
 					i++;
-				vbl += (i - j) * (*p->width)(p, ' ');
+				dv = (i - j) * (*p->width)(p, ' ');
+				vbl += dv;
+				vend += dv;
 				break;
 			}
 			if (ASCII_NBRSP == p->buf[i]) {
@@ -260,7 +263,6 @@ term_flushln(struct termp *p)
 				p->viscol += (*p->width)(p, p->buf[i]);
 			}
 		}
-		vend += vbl;
 		vis = vend;
 	}
 

--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

  reply	other threads:[~2010-09-21 23:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-10 21:14 Jason McIntyre
2010-09-15 15:53 ` Kristaps Dzonsons
2010-09-21 23:05   ` Ingo Schwarze [this message]
2010-09-22  7:09     ` Jason McIntyre
2010-09-22  8:11       ` Kristaps Dzonsons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100921230513.GC9516@iris.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).