Re: [help-texinfo] conditional line-breaks for @example text?

[Rick Jones]

On 06/27/2011 11:50 AM, Karl Berry wrote:
> Hi Rick,
>
>      output it results in either truncation, or failure.
>
> Hmm, it should neither truncate nor fail.

I may be mis-interpreting the messages when I try to make the .ps file.

> It should output the long
> line along with an overfull hbox message and black box in the output.

There are certainly plenty of overfull hbox messages when I try to 
create the .ps file - as well as a number of underfull hbox messages.

> You can omit the black boxes by saying @finalout.
>
> (That is, it might be displayed as truncated because of the page width,
> but all the text should be in the output.)

OK.

>      there any way to "conditionally" break the long lines when the output is
>      going to be something where they would be truncated?
>
> Not right now.  Something like that could conceivably be done -- I can
> imagine an option to make spaces into an allowable breakpoint inside
> @example et al.  Then lines inside @example would break instead of fall
> off the right edge of the paper.  I don't see any good way to allow
> breaks after N characters (independent of spaces), though.
>
> Usually if an example's lines are longer than what @smallexample allows,
> they're pretty long for humans to read too.

This is indeed a rather long line for humans to read, but it is a line 
that has grown over the years and needed to remain one line in output - 
I have to assume that people are parsing it with scripts and whatnot. 
Alas, @smallexample still wraps in the pdf version

> One obvious manual solution is to insert @* where you want the line
> breaks.

That will affect all output types equally right?

thanks,

rick jones

> Another ugly option that could be done now is something like
> @quotation
> @t{first address@hidden
> @t{second address@hidden
> @t{third line}
> @end quotation
>
> Then line breaking would happen.  (Presumably you'd automatically
> generate this kind of input, since it would be a pain to type,
> obviously.)  I expect there are other variations possible with combining
> environments, etc.
>
> Best,
> Karl