Hi Dave,
At 2023-05-23T15:24:26-0500, Dave Kemper wrote:
> On 5/21/23, G. Branden Robinson wrote:
> > At 2023-05-13T12:52:06-0500, Dave Kemper wrote:
> >> In Heirloom troff, the space on the first and third lines match.
> >> In groff (both 1.22.4 and 1.23 rc4), the second and third lines do.
> >
On 5/21/23, G. Branden Robinson wrote:
> At 2023-05-13T12:52:06-0500, Dave Kemper wrote:
>> .nf
>> .ss 36
>> foo bar
>> .ss 48
>> foo bar
>> foo\h'1m'bar
>>
>> In Heirloom troff, the space on the first and third lines match. In
>> groff (both 1.22.4 and 1.23 rc4), the second and third lines do.
>
[self-follow-up]
At 2023-05-06T20:59:22-0500, G. Branden Robinson wrote:
> So I have a change pending for groff-next that will make the foregoing
> look more like:
>
> troff:man3/unlocked_stdio.3:123: warning [page 2, 1.8i (diversion '3tbd1,0',
> 0.3i)]: cannot break line
>
> What would build u
At 2023-05-13T12:52:06-0500, Dave Kemper wrote:
> On 5/13/23, G. Branden Robinson wrote:
> >> At 2023-05-10T12:28:02-0500, Dave Kemper wrote:
> >> > And I just learned (or maybe relearned) this is a deviation from
> >> > AT&T troff's .ss units, which are a fixed 1/36 em.
> >
> > I am beginning to
On 5/13/23, G. Branden Robinson wrote:
>> At 2023-05-10T12:28:02-0500, Dave Kemper wrote:
>> > And I just learned (or maybe relearned) this is a deviation from
>> > AT&T troff's .ss units, which are a fixed 1/36 em.
>
> I am beginning to think that it was only Ossanna troff for which that
> was tr
[self-follow-up]
At 2023-05-13T02:03:11-0500, G. Branden Robinson wrote:
> At 2023-05-10T12:28:02-0500, Dave Kemper wrote:
> > On 5/10/23, Dave Kemper wrote:
> > > Nonintuitively, .ss's units aren't in fractions of standard
> > > typographical measurements, but 1/12 of the current font's
> > > or
At 2023-05-10T12:28:02-0500, Dave Kemper wrote:
> On 5/10/23, Dave Kemper wrote:
> > Nonintuitively, .ss's units aren't in fractions of standard
> > typographical measurements, but 1/12 of the current font's ordinary
> > space.
>
> And I just learned (or maybe relearned) this is a deviation from
On 5/10/23, Dave Kemper wrote:
> Nonintuitively, .ss's units aren't in fractions of standard
> typographical measurements, but 1/12 of the current font's ordinary
> space.
And I just learned (or maybe relearned) this is a deviation from AT&T
troff's .ss units, which are a fixed 1/36 em.
This dif
On 5/10/23, G. Branden Robinson wrote:
> But it was interesting
> to me to observe the performance of GNU troff and grotty with literally
> billions of lines of input.
I agree, though it wasn't a completely realistic test, with each line
having only one word on it: no filling, no adjusting (thoug
Hi Alex,
I endorse Dave's critique of your measurement. But it was interesting
to me to observe the performance of GNU troff and grotty with literally
billions of lines of input.
At 2023-05-09T15:37:16-0500, Dave Kemper wrote:
> (I can already hear the questions. "Why is the terminal basic unit
On 5/8/23, Alejandro Colomar wrote:
> I couldn't notice the non-infiniteness. See the following session.
I'm not sure what you thought that test was measuring, but I'm pretty
sure it's not what it was actually measuring.
First, the man macros don't set their page length to INT_MAX. This
was a
Hi Branden,
I pushed this.
Cheers,
Alex
*.mk: Use -wbreak in TROFFFLAGS, and -ww in NROFFFLAGS
We don't need to see all warnings everywhere we call troff(1). Instead,
put all warnings in nroff mode, which we only run for the warnings, and
then only ask for warnings that de
Hi Branden,
On 5/8/23 02:29, G. Branden Robinson wrote:
> Hi Alex,
>
> At 2023-05-07T22:42:05+0200, Alejandro Colomar wrote:
>> $ make build-pre-tbl >/dev/null
>> $ grep 'table wider' .tmp/man/man4/console_codes.4.eqn
>> . tm1 " table wider than line length minus indentation
>> . tm1 " table wi
Hi Alex,
At 2023-05-07T22:42:05+0200, Alejandro Colomar wrote:
> $ make build-pre-tbl >/dev/null
> $ grep 'table wider' .tmp/man/man4/console_codes.4.eqn
> . tm1 " table wider than line length minus indentation
> . tm1 " table wider than line length minus indentation
> . tm1 " table wider than
Hi Alex,
At 2023-05-07T20:13:54+0200, Alejandro Colomar wrote:
> On 5/7/23 04:20, G. Branden Robinson wrote:
> > I'm following the GNU Coding Standards here.
> >
> > https://www.gnu.org/prep/standards/standards.html#Errors
>
> Oh yeah, those. I guess I can't argue much against that practice
> t
On 5/7/23 03:59, G. Branden Robinson wrote:
> Hi Alex,
>
> At 2023-05-03T00:21:33+0200, Alejandro Colomar wrote:
>> On 5/2/23 17:10, G. Branden Robinson wrote:
>>> There isn't really any such thing as a device-dependent warning,
>>> unless you count those thrown by the output driver itself, like
On 5/7/23 04:20, G. Branden Robinson wrote:
> Hi Alex,
>
> At 2023-05-03T01:26:55+0200, Alejandro Colomar wrote:
>>> troff:man3/unlocked_stdio.3:123: warning [p 2, 1.8i, div '3tbd1,0', 0.3i]:
>>> cannot break line
>>>
>>> an.tmac:man4/cciss.4:164: style: blank line in input
>>>
>>> man4/console
Hi Alex,
At 2023-05-03T01:26:55+0200, Alejandro Colomar wrote:
> > troff:man3/unlocked_stdio.3:123: warning [p 2, 1.8i, div '3tbd1,0', 0.3i]:
> > cannot break line
> >
> > an.tmac:man4/cciss.4:164: style: blank line in input
> >
> > man4/console_codes.4:324: warning: table wider than line lengt
Hi Alex,
At 2023-05-03T00:21:33+0200, Alejandro Colomar wrote:
> On 5/2/23 17:10, G. Branden Robinson wrote:
> > There isn't really any such thing as a device-dependent warning,
> > unless you count those thrown by the output driver itself, like
> > grops(1) or grotty(1).
>
> No, I run the output
Hi Alejandro,
Alejandro Colomar wrote on Wed, May 03, 2023 at 01:26:55AM +0200:
> I find it more readable when there's one space between the program
> that generates the warning and the file. That's what mandoc(1) does,
> and in general, what any program that relies on perror(3) does (I'm
> assu
Hi Branden,
On 5/3/23 00:21, Alejandro Colomar wrote:
>
> troff:man3/unlocked_stdio.3:123: warning [p 2, 1.8i, div '3tbd1,0', 0.3i]:
> cannot break line
>
> an.tmac:man4/cciss.4:164: style: blank line in input
>
> man4/console_codes.4:324: warning: table wider than line length minus
> indenta
> _cannot_ launch the formatter without a valid device description.
>
>> For that, one could enable -ww in the main target, and then only
>> enable device-dependent warnings for the other targets.
>
> There isn't really any such thing as a device-dependent warning
ww in the main target, and then only
> enable device-dependent warnings for the other targets.
There isn't really any such thing as a device-dependent warning, unless
you count those thrown by the output driver itself, like grops(1) or
grotty(1).
> Would you create a category -wdev
-dependent warnings for the other targets.
Would you create a category -wdev that only enables warnings that would
be different for different devices? Or maybe -wpdf and similar ones.
I expect issues about fonts, for example, will not be reported in -Tutf8
but will be in -Tpdf.
Cheers,
Alex
--
<h
24 matches
Mail list logo
