Re: [docbook2X] arg-or-separator - remove whitespace

[Michael S. <sm...@xm...>]

Steve Cheng <el...@ip...> writes:

> On June 30, 2003 12:36 pm, Michael Smith wrote:
> > For example, if I want to render a synopsis like this:
> >
> >   imdirsync [-host <hostName>] [-con <N>]  [-run <dump|part|build|inst>]
> >
> > ..if I keep arg-or-separator set to the default " | " value, I get:
> >
> >   imdirsync [-host <hostName>] [-con <N>] [-run <dump | part | build |
> >   inst>]
> >
> > That is, the group gets broken across a line -- definely not what I want
> > or expect.
> 
> Yes, I see what you mean.
> But I have an uneasy feeling that whether to insert whitespace depends on the 
> situation. For example, python(1) does this:
> 
> # python [ -d ] [ -i ] [ -O ] [ -S ] [ -t ] [ -u ] [ -v ] [ -x ] [ -h ]
> #       [ -V ] [ -W argument ]
> #              [ -c command | script | - ] [ arguments ]
> 
> The whitespace for the -c parameter make sense, it seems, because
> "command", "script" are meta-variables, and "-" is something totally different 
> altogether. (Your example is different, I think, because "dump", "part", 
> "build", "inst" essentially form a homogeneous list of tokens.)

OK, I see

> In the TDG, HTML rendition (a fairly old version),
> I notice that the example in the cmdsynopsis refentry does use whitespace.
> (Of course, *that* is HTML and this is man pages.)

Well, I guess it's not so much an issue of whitespace as it is an issue
of linebreaks. In HTML, we can use a non-breaking space -- &#160; Is
there an equivalent in groff? That is, a character that'll render as a
space, but not won't get broken across a line?

In your Python example above, because of the whitespace, I could see the
synopsis getting rendered like, for example:

  python [ -d ] [ -i ] [ -O ] [ -S ] [ -t ] [ -u ] [ -v ] [ -x ] [ -h
  ] [ -V ] [ -W argument ] [ -c command | script | - ] [ arguments ]

..or something. So, it's kind of the same issue as far as the space
after/before the opening/closing square brackets goes. Most man pages I
see tend to omit that square-bracket whitespace, I think.

> I wonder if there is a right/better way to fix it --- optional parameters,

I'd vote for doing that -- parameterizing whitespace yes/no in
arg-or-separator and in arg-choice-*-start and arg-choice-*-end 

> or even heuristic detection(!) of whether to put the whitespace or
> not.

That'd be great, but I'm sure it'd take a chunk of time and work to
implement.

  --Mike